Tech 导读 本文重点介绍了MySQL数据库性能优化的常见手段、底层架构实现原理、互联网医院建设过程中的几个典型案例；读者可以通过本文了解到日常开发中的注意事项、数据库性能优化的解决思路、如何规避隐藏规则带来的风险等几个方面的知识。
MySQL数据库是我们整个系统中最核心最宝贵的资源，为了更好的使用每个公司都会制定对应的使用手册来规范大家的使用，也就是标题中提到的军规，接下来给大家分享下58到家的MySQL军规哦，希望对你能有所帮助。
就是查tableStore失败了，在日志平台查下看到，因为查询参数太长，日志平台直接进行了截断！！！
日志二和日志三sql完全一样，其实是两次调用(同一时刻并发调用)，调用条件不同，但在程序处理时这条SQL的where条件一样而已
解读：高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧。
MySQL中存在着许多的锁，按照锁的作用范围可以分为全局锁、表级锁和行级锁，每种锁级别下又可划分更细粒度的锁。文章不会涉及锁的具体实现细节，主要介绍的是碰到锁时的现象和其背后原理。由于日常开发阶段主要打交道的是行级锁，所以你可以重点关注行级锁的特性！
点击上方蓝字每天学习数据库 一起构建MySQL知识网络，我是林晓斌，今天的文章我们从索引说起。 林晓斌 林晓斌，网名丁奇，腾讯云数据库负责人，数据库领域资深技术专家。作为活跃的MySQL社区贡献者，丁奇专注于数据存储系统、MySQL源码研究和改进、MySQL性能优化和功能改进，在业务场景分析、系统瓶颈分析、性能优化方面拥有丰富的经验。其创作的《MySQL实战45讲》专栏受众已逾2万人。 你一定知道了，索引的作用是加快查询速度。比如有一个人口信息表，如果没有加索引，你要按照身份证号查找一个人，就得全表
互联网MySQL数据库应用潜规则 高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算还是上移吧。 📷 军规适用场景：并发量大、数据量大的互联网业务 军规：介绍内容 解读：讲解原因，解读比军规更重要 一、基础规范 （1）必须使用InnoDB存储引擎 解读：支持事务、行级锁、并发性能更好、CPU及内存缓
MySQL 大表数据添加新字段 有时候我们在测试环境给一个表添加字段,但是在线上环境添加一个字段,却极其的慢。原因是线上的数据库一般会存有大量的数据(百万级,千万级),基本的添加字段方式在线上数据库已经不太合适了。 > alter table user add column flag tinyint(1) default 0; 基本添加方式,大量数据的表不推荐。执行加字段操作就会锁表，这个过程可能需要很长时间甚至导致服务崩溃。 解决方案 扩展新表方案 创建一个新表user_ext(id,user_id,f
背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注：MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于I
文章摘要 在线上环境遇到数据库死锁问题该如何分析并解决问题呢？ 虽然很多童鞋在学数据库课程时都了解数据库隔离级别、死锁和事务等概念，但在测试/线上环境遇到死锁却不一定能够及时分析并解决这类问题。本文主要以作者在测试环境中遇到的一个死锁Case说起，首先还原出现死锁的现场和条件，并结合排查业务应用工程日志、MySQL数据库状态信息等方式，同时给出MySQL锁的基本概念，再通过阅读日志深入定位并分析出现死锁的原因，最后讲下MySQL InnoDB的加锁原理以及如降低死锁发生的机率。 一、 出现死
1、高可用分析：高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。
注：图中圈出的是数据同步的地方，数据同步（从库从主库拉取binlog日志，再执行一遍）是需要时间的，这个同步时间内主库和从库的数据会存在不一致的情况。如果同步过程中有读请求，那么读到的就是从库中的老数据。如下图。
线上有个定时任务，这个任务需要查询一个表几天范围内的一些数据做一些处理，每隔十分钟执行一次，直至成功。
1.高可用分析： 高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。
军规适用场景：并发量大、数据量大的互联网业务 军规：介绍内容 解读：讲解原因，解读比军规更重要
墨墨导读：事实上，关系型数据库今天已经形成了『两商用加两开源，并驾齐驱四天王』的整体格局。
最近，又遇到了慢 SQL，简单的看了下，又是因为 MySQL 本身优化器还有查询计划估计不准的问题。SQL 如下：
上周五的时候，在线上执行了2个MongoDB的操作，这俩操作跟平时的相比，其实都还有一些特殊性，所以简单
本文包含数据库架构原则、常见的四种架构方案、两种一致性解决方案、以及作者个人的一些见解。
1、高可用分析：高可用，主库挂了，keepalive（只是一种工具）会自动切换到备库。这个过程对业务层是透明的，无需修改代码或配置。 2、高性能分析：读写都操作主库，很容易产生瓶颈。大部分互联网应用读多写少，读会先成为瓶颈，进而影响写性能。另外，备库只是单纯的备份，资源利用率50%，这点方案二可解决。 3、一致性分析：读写都操作主库，不存在数据一致性问题。 4、扩展性分析：无法通过加从库来扩展读性能，进而提高整体性能。 5、可落地分析：两点影响落地使用。第一，性能一般，这点可以通过建立高效的索引和引入缓存来增加读性能，进而提高性能。这也是通用的方案。第二，扩展性差，这点可以通过分库分表来扩展。
上周陪同之前一起工作的同事去面试（乔治，小袁，鹏飞（面试人）），第一站是去深圳，第二站上海，第三站杭州。面试什么公司我在这里就不多说了，你们知道是一线公司就行。其实本来真的没打算写这篇文章，主要是自己的记忆力不是很好，再者是最近好多人询问2018年最新的面试题有点多，我实在回答不过来，而且怕为了避免重复回答，给自己省点力气，干脆就在这里统一回复了。 说实话，虽作为陪同人，面试的时候我是不可以一同进去面试的，鹏飞在面试完后出来也是凭借他模糊的记忆，来慢慢回忆当时HR问的几个问题，以下是我整理的一些面试题，虽然不是很完整，但差不多也是必问的几个题目了（前言告诉大家，面试的答案我就不一个一个的写出来了，毕竟等级的不同，回答时的答案也不同，这全靠大家自己慢慢领悟了）我能帮的也只有这么多了。以下便是面试题。
增加字段相信大家应该都不陌生，随手就可以写出来，给 MySQL 一张表加字段执行如下 sql 就可以了：
今天要分享的是在生产环境中出现的一次算得上比较诡异的死锁事件, 不过庆幸的是没有产生较大的业务损失.
最近线上突然发现一张表每天会产生500w条的数据，一个月下来发现已经接近8000w条的数据，达到90G之大的数据，之前在系统没有升级之前一年才产生100w左右的记录，估计开发的程序或者逻辑出现问题了，不管怎么样，作为运维发生问题，第一时间先以解决问题为第一位，所以这里总结一下删除大表数据的经验。
上周陪同之前一起工作的同事去面试（乔治，小袁，鹏飞（面试人）），第一站是去深圳，第二站上海，第三站杭州。面试什么公司我在这里就不多说了，你们知道是一线公司就行。其实本来真的没打算写这篇文章，主要是自己
我们码农平时大多数时间都在撸码或者撸码的路上，很少关注mysql的一些底层原理，当出现问题时没能力第一时间解决问题，出现问题后不去层层剖析问题产生的原因，后续也就可能无法避免或者绕开同类的问题。因此不要单纯做Ctrl+c和Ctrl+V，而是一边仰望星空(目标规划)，一边脚踏实地去分析每个问题。 在mysql系列专栏里面，我深入浅出的总结了mysql相关知识，感兴趣的话可以去阅读，有问题就可以随时相互交流学习。
又和大家见面了！又两周过去了，我的云笔记里又多了几篇写了一半的文章草稿。有的是因为质量没有达到预期还准备再加点内容，有的则完全是一个灵感而已，内容完全木有。羡慕很多大佬们，一周能产出五六篇文章，给我两个肝我都不够。好了，不多说废话了…
Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统。Fusion-NewSQ兼容了MySQL协议，支持二级索引功能，提供超大规模数据持久化存储和高性能读写。
早上刚来，有个业务需求，是要变更一张表的表结构，我登陆到服务器上看了看之前的变结构，大概信息如下：
查阅了官方文档，我们可以了解到，插入意向锁（Insert Intention Locks ）其实是一种特殊的gap lock，在行插入前，要获取这个锁（所以这个锁是在行排它锁之前获取）。
虽然很多童鞋在学数据库课程时都了解数据库隔离级别、死锁和事务等概念，但在测试/线上环境遇到死锁却不一定能够及时分析并解决这类问题。本文主要以作者在测试环境中遇到的一个死锁Case说起，首先还原出现死锁的现场和条件，并结合排查业务应用工程日志、MySQL数据库状态信息等方式，同时给出MySQL锁的基本概念，再通过阅读日志深入定位并分析出现死锁的原因，最后讲下MySQL InnoDB的加锁原理以及如降低死锁发生的机率。
最近做了一些分布式事务的项目，对事务的隔离性有了更深的认识，后续写文章聊分布式事务。今天就复盘一下单机事务的隔离性是如何实现的？
又和大家见面了！又两周过去了，我的云笔记里又多了几篇写了一半的文章草稿。有的是因为质量没有达到预期还准备再加点内容，有的则完全是一个灵感而已，内容完全木有。羡慕很多大佬们，一周能产出五六篇文章，给我两个肝我都不够。好了，不多说废话了...
MySQL Online DDL 功能从 5.6 版本开始正式引入，发展到现在的 8.0 版本，经历了多次的调整和完善。本文主要就 Online DDL 的发展过程，以及各版本的区别进行总结。其实早在 MySQL 5.5 版本中就加入了 INPLACE DDL 方式，但是因为实现的问题，依然会阻塞 INSERT、UPDATE、DELETE 操作，这也是 MySQL 早期版本长期被吐槽的原因之一。
面试官反问的大概意思是，MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗？
数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
在遇到慢 SQL 情况时，不能简单的把原因归结为 SQL 编写问题(虽然这是最常见的因素)，实际上导致慢 SQL 有很多因素，甚至包括硬件和 mysql 本身的 bug。根据出现的概率从大到小，罗列如下：
事务更新 comment_subject，comment_index，comment_content 三张表，其中 content 属于非强制需要一致性考虑的。可以先写入 content，之后事务更新其他表。即便 content 先成功，后续失败仅仅存在一条 ghost 数据。这样做虽然性能没有提升多少，但是content表是有可能替代为KV数据库的。
讲完索引，接下来聊一聊MySQL的锁。数据库锁设计的初衷是解决并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理的控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
当数据库中有多个操作需要修改同一数据时，不可避免的会产生数据的脏读。这时就需要数据库具有良好的并发控制能力，这一切在 MySQL 中都是由服务器和存储引擎来实现的。解决并发问题最有效的方案是引入了锁的机制，锁在功能上分为共享锁 (shared lock) 和排它锁 (exclusive lock) 即通常说的读锁和写锁； 锁的粒度上分行锁和表锁，表级锁MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)
一 序言 在运维线上M-M 架构的MySQL数据库时,接收的比较多关于主备延时的报警:
这篇文章我想来聊聊 MySQL 的锁是怎么加上的，为啥想聊这个呢？主要是因为业务中我们或多或少都会使用到锁，毕竟锁是保障我们数据安全性的关键法宝。但是由于不了解原理，往往可能导致我们在”刻意“或者”无意“的使用场景下，带来潜在的性能问题，轻则导致处理能力降低，重则可能会拖垮我们的 DB，因此需要对锁的原理以及使用场景有比较全面的了解，才能更好地驾驭，避免给我们带来不必要的业务隐患。
腾讯云数据库国产数据库专题线上技术沙龙正在火热进行中，3月5日林晓斌（丁奇）的2020首场分享已经结束，没来得及参与的小伙伴不用担心，下面就给大家奉上直播视频全程回顾，流量伤不起的小伙伴们也可以看由腾讯云数据库整理好的文字稿，干货满满，保证让你有所收获。 关注“腾讯云数据库”公众号，回复“0305丁奇”，即可下载直播分享PPT。 图文直播回顾 大家好！我是腾讯云数据库的林晓斌，在社区活动的时候网名叫丁奇，跟比较多的同学互相认识，今天跟大家就是找个机会聊一下数据库的基础，还有腾讯自研数据库的技术演进，我相
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
