[总结]MySQL经验

SQL连接图解演示-共七页

数据库底层数据结构与数据库索引类型

跳表，哈希索引，SSTable，LSM树，B树，倒排索引，R树，后缀树。

如果MySQL磁盘满了，会发生什么？还真被我遇到了！

要进行磁盘碎片化整理。原因是datafree占据的空间太多，看看自己的系统的datafree大不大 show table status from 表名;

100G内存下，MySQL查询200G大表会OOM么？

MySQL中ORDER BY与LIMIT 不要一起用，有大坑

如果order by的列有相同的值时，mysql会随机选取这些行，为了保证每次都返回的顺序一致可以额外增加一个排序字段（比如：id），用两个字段来尽可能减少重复的概率。

8种常见SQL错误用法

mybatis-plus团队新作：mybatis-mate 轻松搞定数据权限

你在 Docker 中跑 MySQL？恭喜你，可以下岗了！

MySQL模糊查询再也用不着 like+% 了  fulltext

这个 MySQL bug 99% 的人会踩坑！

reconsidering_access_paths_for_index_ordering  导致未使用索引。主要原因是由于我们使用了 order by id asc 这种基于 id 的排序写法，优化器认为排序是个昂贵的操作，所以为了避免排序，并且它认为 limit n 的 n 如果很小的话即使使用全表扫描也能很快执行完，所以它选择了全表扫描。也就避免了 id 的排序（全表扫描其实就是基于 id 主键的聚簇索引的扫描，本身就是基于 id 排好序的）。网上有不少人反馈这个问题，而且出现这个问题基本只与 SQL 中出现 order by id asc limit n 这种写法有关。如果 n 比较小很大概率会走全表扫描，如果 n 比较大则会选择正确的索引。

主要有两种方案

1. 使用 force index 来强制使用指定的索引。

select * from order_info force index(idx_uid_stat) where uid = 5837661 order by id asc limit 1

2. 使用 order by (id+0) 方案。

select * from order_info where uid = 5837661 order by (id+0) asc limit 1

使用MySQL，请用好 JSON 这张牌！