摘要：
文章提出了数据库在高并发高请求的情况下出现的一些性能问题，这里警示DB人员饮鸩止渴提高性能操作：应对短连接风暴，切掉空闲进程（部分事务回滚），max connect参数（过高有损性能），还有SQL语句本身原因，正如之前讨论过的索引：没设计、选错了、有，但没用上，以及应对QPS（单位时间查询）过高必须下掉功能时：白名单，用户删除，语句重写（要分环境，看公司运维规范程度） 阅读全文
摘要：
该文章深刻揭示了一点：加索引=行锁+间隙锁=（next-key lock），分析了加锁的规则：对主键（唯一索引），普通非唯一索引进行等值与范围查询的加锁。这篇文章我认为收获最大的是让我们知道“明明对一行加了锁，为什么在他相邻部分，或是相相邻部分无法插入数据（这根主键类型，是单个还是范围查询有关，就算他的逻辑是一样的）”,值的一提的是事务的for update更新与delete加锁规则是一样的，这意味着在你在大量插入的业务下删除数据可能会导致“数据insert失败”，解决方式是加limit，减少间隙锁的范围。 阅读全文
摘要：
文章以幻读起手，以假设的方式钻“加锁”的空子，引出“间隙锁”（也就是现在的mysql锁机制），但就算这样，在可重复读的隔离级别下也会发生死锁，即使对行锁有准确的认识，也可能会因为间隙锁翻车，像两个session同时占用一个主键（注意：与行锁不同，他没有锁之间的冲突）插入操作时都会被对方的间隙锁挡住（虽然很行锁很相似，但他们的加锁位置不同） 阅读全文
摘要：
和上篇文章不同，文章探讨了我们正常执行sql语句慢的原因：第一：其他进程正在DML写锁，需要kill或等待，第二flush刷盘flush在关闭session途中被别的命令堵住了，进一步堵住select查询，如sleep，第三，在引擎层面update存在且不提交写锁也会被堵住（这边还介绍了kill query与kill的去别，十分实用），第四：查询慢还可以是索引：走主键顺序扫描(可以在慢查询日志里找)，第五：就算只扫描一行，但还是慢，还可以是事务一直没提交，造成undolog回滚日志特别长，如果没有加“lock in share mode”，那读取数据得先回滚到上一个版本再读取。 阅读全文
摘要：
该文章中，提出了”有很多看上去逻辑相同，但性能却差异巨大的 SQL 语句”提出索引树罢工的现象分析了三个原因：where后面函数操作，多表查询字段类型冲突，utf-8字符编码冲突（俗称隐式类型转换），正因如此索引就会罢工（explain中key显示NULL），这边还顺便介绍了驱动表（多表查询from后面的是被驱动表），最后要强调的是select * from table where id + 1 = 10000 这个 SQL 语句与select * from table where id = 10000-1（这道题体现文章核心思想） 两者间查询效率相差极大 阅读全文
摘要： 
该文章承接上一篇order by排序，进一步提出随机挑选数据的问题，站在大量数据查询的情况下：提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端：既要建立临时表排序（这里优化器使用的rowid排序）而且如果表中有一万条数据，那么扫描行数高达2万零三条（虽然sort_buffer排序不涉及表操作，不扫描表，这里需要注意临时表，上一张没细讲，就是因为使用另一个引擎，先后从memory到innodb引擎读了1万条数据），此外，拓宽了上一张rowid主键的范围（也可以是系统建的默认递增主键），还有优先队列排序法也挺有意思（与归并排序算法区分下），为了解决上面随机查询的弊端，我们提出了随机排序算法（这里要注意数据空洞，不能用大小比较）利用变量，字符串拼接，预处理语句十分有意思 阅读全文
该文章承接上一篇order by排序，进一步提出随机挑选数据的问题，站在大量数据查询的情况下：提出select word from words order by rand() limit 3;这种我们经常使用的查询语句的弊端：既要建立临时表排序（这里优化器使用的rowid排序）而且如果表中有一万条数据，那么扫描行数高达2万零三条（虽然sort_buffer排序不涉及表操作，不扫描表，这里需要注意临时表，上一张没细讲，就是因为使用另一个引擎，先后从memory到innodb引擎读了1万条数据），此外，拓宽了上一张rowid主键的范围（也可以是系统建的默认递增主键），还有优先队列排序法也挺有意思（与归并排序算法区分下），为了解决上面随机查询的弊端，我们提出了随机排序算法（这里要注意数据空洞，不能用大小比较）利用变量，字符串拼接，预处理语句十分有意思 阅读全文
摘要：
该文章简述了order by排序的两种策略，一个是全字段排序：将字段全部放到sort__buffer里面，在内存内部排序（内存要求高），另一个是rowid排序：将order后面的指定字段与ID一起扔到内存排序，但因为如果查询有其他字段，他会再次回到表进行一次主键索引（因此相对而言内存消耗更小），之后为了更加快速，我们想到了前面的覆盖索引（这样可以避免创建临时表，前面的两个策略都创建了临时表），大概就是建立联合索引将我们所要查询的字段全部包涵进去，而且这还免去的排序，快的一批，但这样会加重后续索引维护，各有利弊 阅读全文
摘要：
第十四讲：答疑文章（一）：日志和索引相关问题 简概： 到目前为止，我已经收集了 47 个问题，很难通过今天这一篇文章全部展开。所以，我就先从中找了几个联系非常紧密的问题，串了起来，希望可以帮你解决关于日志和索引的一些疑惑。而其他问题，我们就留着后面慢慢展开吧。 我在第 2 篇文章《日志系统： 阅读全文
摘要：
第十三讲：count(*)这么慢，我该怎么办？ 简概： count(*) 的实现方式 你首先要明确的是，在不同的 MySQL 引擎中，count() 有不同的实现方式。 MyISAM 引擎把一个表的总行数存在了磁盘上，因此执行 count() 的时候会直接返回这个数，效率很高； 而 InnoDB 阅读全文
摘要：
第十二讲: 为什么表数据删掉一半，表文件大小不变？ 简概： 问题：表删掉了一半的数据，表文件的大小还是没变？ 经常会有同学来问我，我的数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小还是没变？ InnoDB 的表回收 那么今天，我就和你聊聊数据库表的空间回收，看看如何解 阅读全文