10-2 MySQL 索引优化与查询优化

汪凤秀 發表於 2025-7-2 14:38:00

<h1 id="10-2-mysql-索引优化与查询优化">10-2 MySQL 索引优化与查询优化</h1>
@
<hr>
这篇文章是我蹲在《尚硅谷》-康师傅博主家的 WiFi 上(不是)，连夜 Ctrl+C / V 俩的镇站神文。
这篇转载只是为了，跟大家分享好内容，没有任何商业用途。如果你喜欢这篇文章，请一定要去原作者 B站《尚硅谷-MySQL从菜鸟到大牛》看看，说不定还能发现更多宝藏内容呢！
<h1 id="7-filesort算法双路排序和单路排序">7. filesort算法：双路排序和单路排序</h1>
排序的字段若不在索引列上，则filesort会有两种算法：双路排序和单路排序
双路排序（慢）
<ul>
<li>MySQL 4.1之前是使用双路排序，字面意思就是两次扫描磁盘，最终得到数据，读取行指针和 order by列，对他们进行排序，然后扫描已经排序好的列表，按照列表中的值重新从列表中读取对应的数据输出</li>
<li>从磁盘取排序字段，在buffer进行排序，再从磁盘取其他字段。</li>
</ul>
取一批数据，要对磁盘进行两次扫描，众所周知，IO是很耗时的，所以在mysql4.1之后，出现了第二种改进的算法，就是单路排序。
单路排序（快）
从磁盘读取查询需要的所有列，按照order by列在buffer对它们进行排序，然后扫描排序后的列表进行输出，它的效率更快一些，避免了第二次读取数据。并且把随机IO变成了顺序IO，但是它会使用更多的空间，因为它把每一行都保存在内存中了。
结论及引申出的问题
<ul>
<li>由于单路是后出的，总体而言好过双路</li>
<li>但是用单路有问题
<ul>
<li>在sort_buffer中，单路要比多路多占用很多空间，因为单路是把所有字段都取出，所以有可能取出的数据的总大小超出了<code>sort_buffer</code>的容量，导致每次只能取<code>sort_buffer</code>容量大小的数据，进行排序（创建tmp文件，多路合并），排完再取sort_buffer容量大小，再排...从而多次I/O。</li>
<li>单路本来想省一次I/O操作，反而导致了大量的I/O操作，反而得不偿失。</li>
</ul>
</li>
</ul>
优化策略
1. 尝试提高 sort_buffer_size 
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/4314901b31fa4da6a1353e96fae945f6~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=g4x6FpoEwDZxrasOUXtpLkVCUF8%3D">
<ol start="2">
<li>尝试提高 max_length_for_sort_data</li>
</ol>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/cdb7bbbd3dc04afa888658ae547473c3~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=XEa1aujwkzU9Rqn1iITFmxpinNQ%3D">
<ol start="3">
<li>Order by 时select * 是一个大忌。最好只Query需要的字段。</li>
</ol>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/48fc2bfade6144a5a259ebdaf5290768~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=%2FZXVLQLdYryIqWfaWf9WvPwDLlg%3D">
<h1 id="8-group-by优化">8. GROUP BY优化</h1>
<ul>
<li>group by 使用索引的原则几乎跟order by一致，group by 即使没有过滤条件用到索引，也可以直接使用索引。</li>
<li>group by 先排序再分组，遵照索引建的最佳左前缀法则</li>
<li>当无法使用索引列，增大 max_length_for_sort_data 和 sort_buffer_size 参数的设置</li>
<li>where效率高于having，能写在where限定的条件就不要写在having中了</li>
<li>减少使用order by，和业务沟通能不排序就不排序，或将排序放到程序端去做。Order by、group by、distinct这些语句较为耗费CPU，数据库的CPU资源是极其宝贵的。</li>
<li>包含了order by、group by、distinct这些查询的语句，where条件过滤出来的结果集请保持在1000行以内，否则SQL会很慢。</li>
</ul>
<h1 id="9-优化分页查询">9. 优化分页查询</h1>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/2cf4f5e1badb468f92d004d3f4090fd1~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=WUZhexmonR3sJFJA8sU4RWclJdk%3D">
优化思路一
在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。
<pre><code class="language-mysql">EXPLAIN SELECT * FROM student t,(SELECT id FROM student ORDER BY id LIMIT 2000000,10) a WHERE t.id = a.id;
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/3b4b727742cd4a7aa45228bc52ae9b1b~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=nwCu1XvxRzqFrb9tG27l00kl19k%3D">
优化思路二
该方案适用于主键自增的表，可以把Limit 查询转换成某个位置的查询。
<pre><code class="language-mysql">EXPLAIN SELECT * FROM student WHERE id > 2000000 LIMIT 10;
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/368625a986074f718d8a8591a2b8f3f0~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=C5JCgl77zpCt5wN5Zr35c8dgHOA%3D">
<h1 id="10-优先考虑覆盖索引">10. 优先考虑覆盖索引</h1>
<h2 id="101-什么是覆盖索引">10.1 什么是覆盖索引？</h2>
理解方式一：索引是高效找到行的一个方法，但是一般数据库也能使用索引找到一个列的数据，因此它不必读取整个行。毕竟索引叶子节点存储了它们索引的数据；当能通过读取索引就可以得到想要的数据，那就不需要读取行了。一个索引包含了满足查询结果的数据就叫做覆盖索引。
理解方式二：非聚簇复合索引的一种形式，它包括在查询里的SELECT、JOIN和WHERE子句用到的所有列（即建索引的字段正好是覆盖查询条件中所涉及的字段）。
简单说就是， <code>索引列+主键</code> 包含 <code>SELECT 到 FROM之间查询的列</code> 。
举例一：
<pre><code># 删除之前的索引
DROP INDEX idx_age_stuno ON student;
CREATE INDEX idx_age_name ON student(age, NAME);
EXPLAIN SELECT * FROM student WHERE age <> 20;
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/a8092efce1f04c5aa5f5b05f87f96bd6~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=Jap2%2FCFFMIyW4zB1YZQWYGI%2BoSo%3D">
举例二：
<pre><code class="language-mysql">EXPLAIN SELECT * FROM student WHERE NAME LIKE '%abc';
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/aaf87eff65d544ee95e2c0c13096f932~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=y9o1wkz5bU%2FwcAxjROrgzzhpOP8%3D">
<pre><code class="language-mysql">CREATE INDEX idx_age_name ON student(age, NAME);
EXPLAIN SELECT id,age,NAME FROM student WHERE NAME LIKE '%abc';
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/6d873c470f864f5c8e6133cf7b08f2f9~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=DANHn%2B%2BapOSa6wBi2shqXUDgf1E%3D">
上述都使用到了声明的索引，下面的情况则不然，查询列依然多了classId,结果是未使用到索引：
<pre><code class="language-mysql">EXPLAIN SELECT id,age,NAME,classId FROM student WHERE NAME LIKE '%abc';
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/c68241c69f944a2e9882f77c0ba1a616~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=atuLhu7H5J3sw%2FsWChRpjWvenuE%3D">
<h2 id="102-覆盖索引的利弊">10.2 覆盖索引的利弊</h2>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/156594807be846a99401810ce6013e99~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=1twr4SRerXxzPk%2B9PFhVuuhGT4k%3D">
<h2 id="103-如何给字符串添加索引">10.3 如何给字符串添加索引</h2>
有一张教师表，表定义如下：
<pre><code class="language-mysql">create table teacher(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb;
</code></pre>
讲师要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：
<pre><code class="language-mysql">mysql> select col1, col2 from teacher where email='xxx';
</code></pre>
如果email这个字段上没有索引，那么这个语句就只能做 <code>全表扫描</code> 。
<h2 id="104-前缀索引">10.4 前缀索引</h2>
MySQL是支持前缀索引的。默认地，如果你创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。
<pre><code class="language-mysql">mysql> alter table teacher add index index1(email);
#或
mysql> alter table teacher add index index2(email(6));
</code></pre>
这两种不同的定义在数据结构和存储上有什么区别呢？下图就是这两个索引的示意图。
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/804421778993434abc42f1f2f9f5ecc1~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=3s2byQOfXR9nmGH2vTX%2B1RQKuFI%3D">
以及
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/251385aced1649bb8f7aa24f2d21bfec~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=0cz90axgsU0g%2F485%2Fm9Qph2HutU%3D">
如果使用的是index1（即email整个字符串的索引结构），执行顺序是这样的：
<ol>
<li>从index1索引树找到满足索引值是’ zhangssxyz@xxx.com’的这条记录，取得ID2的值；</li>
<li>到主键上查到主键值是ID2的行，判断email的值是正确的，将这行记录加入结果集；</li>
<li>取index1索引树上刚刚查到的位置的下一条记录，发现已经不满足email=' zhangssxyz@xxx.com ’的条件了，循环结束。</li>
</ol>
这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。
如果使用的是index2（即email(6)索引结构），执行顺序是这样的：
<ol>
<li>从index2索引树找到满足索引值是’zhangs’的记录，找到的第一个是ID1；</li>
<li>到主键上查到主键值是ID1的行，判断出email的值不是’ zhangssxyz@xxx.com ’，这行记录丢弃；</li>
<li>取index2上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出ID2，再到ID索引上取整行然后判断，这次值对了，将这行记录加入结果集；</li>
<li>重复上一步，直到在idxe2上取到的值不是’zhangs’时，循环结束。</li>
</ol>
也就是说 使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本前面已经讲过区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。
<h2 id="105--前缀索引对覆盖索引的影响">10.5前缀索引对覆盖索引的影响</h2>
<blockquote>
结论：使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素。
</blockquote>
<h1 id="10-索引下推">10. 索引下推</h1>
<h2 id="101-使用前后对比">10.1 使用前后对比</h2>
ndex Condition Pushdown(ICP)是MySQL 5.6中新特性，是一种在存储引擎层使用索引过滤数据的一种优化方式。
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/738f5b56fe5046ebaa51d2358fe589fd~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=Rq6mr8A6Q4KWUGz6WrBd1gyOZVY%3D">
<h2 id="102-icp的开启关闭">10.2 ICP的开启/关闭</h2>
<ul>
<li>默认情况下启动索引条件下推。可以通过设置系统变量<code>optimizer_switch</code>控制：<code>index_condition_pushdown</code></li>
</ul>
<pre><code class="language-mysql"># 打开索引下推
SET optimizer_switch = 'index_condition_pushdown=on';

# 关闭索引下推
SET optimizer_switch = 'index_condition_pushdown=off';
</code></pre>
<ul>
<li>当使用索引条件下推是，<code>EXPLAIN</code>语句输出结果中<code>Extra</code>列内容显示为<code>Using index condition</code>。</li>
</ul>
<h2 id="103-icp使用案例">10.3 ICP使用案例</h2>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/3dcdefa725834591ab286b6c7e56e762~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=ZCYCXiw361s7Xe%2FaS0XVFEsdJg0%3D">
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/1802a51ff78b445e8cf11327654c12b3~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=OIjsK%2BJaRgzITioAz3SX5naJzWk%3D">
<ul>
<li>主键索引 (简图)</li>
</ul>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/3d123652540a47a8ba40f31846a50440~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=VIetD%2BHZhJDJ6drWbqkP4I0I7v0%3D">
二级索引zip_last_first (简图，这里省略了数据页等信息) 
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/b3fe1441de6b4720957488dcf4d098ad~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=t4BwDlb0tmK%2Bsb62GAdwBrdsoec%3D">
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/584a7565820d4b94bbf771208fa78f03~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=OffCz8aDWnUAjtEcu8q9ZFeDKw4%3D">
<h2 id="104-开启和关闭icp性能对比">10.4 开启和关闭ICP性能对比</h2>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/9d9db4a919e144c3a9a701c519a39f70~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=SLrTz60E9OlKUjHP8mnajeZ3CIQ%3D">
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/84a5f2ec36f44313b4b87938b33fac14~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=9k8xcxlJoMvl7NyqkTVTDEOGYjw%3D">
<h2 id="105-icp的使用条件">10.5 ICP的使用条件</h2>
<ol>
<li>如果表的访问类型为 range 、 ref 、 eq_ref 或者 ref_or_null 可以使用ICP。</li>
<li>ICP可以使用<code>InnDB</code>和<code>MyISAM</code>表，包括分区表<code>InnoDB</code>和<code>MyISAM</code>表</li>
<li>对于<code>InnoDB</code>表，ICP仅用于<code>二级索引</code>。ICP的目标是减少全行读取次数，从而减少I/O操作。</li>
<li>当SQL使用覆盖索引时，不支持ICP优化方法。因为这种情况下使用ICP不会减少I/O。</li>
<li>相关子查询的条件不能使用ICP</li>
</ol>
<h1 id="11-普通索引-vs-唯一索引">11. 普通索引 vs 唯一索引</h1>
从性能的角度考虑，你选择唯一索引还是普通索引呢？选择的依据是什么呢？
假设，我们有一个主键列为ID的表，表中有字段k，并且在k上有索引，假设字段 k 上的值都不重复。
这个表的建表语句是：
<pre><code class="language-mysql">mysql> create table test(
id int primary key,
k int not null,
name varchar(16),
index (k)
)engine=InnoDB;
</code></pre>
表中R1~R5的(ID,k)值分别为(100,1)、(200,2)、(300,3)、(500,5)和(600,6)。
<h2 id="11-1-查询过程">11. 1 查询过程</h2>
假设，执行查询的语句是 select id from test where k=5。
<ul>
<li>对于普通索引来说，查找到满足条件的第一个记录(5,500)后，需要查找下一个记录，直到碰到第一个不满足k=5条件的记录。</li>
<li>对于唯一索引来说，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索。</li>
</ul>
那么，这个不同带来的性能差距会有多少呢？答案是，微乎其微。
<h2 id="112-更新过程">11.2 更新过程</h2>
为了说明普通索引和唯一索引对更新语句性能的影响这个问题，介绍一下change buffer。
当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下， <code>InooDB会将这些更新操作缓存在change buffer中</code> ，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。
将change buffer中的操作应用到原数据页，得到最新结果的过程称为 merge 。除了 <code>访问这个数据页</code> 会触发merge外，系统有 <code>后台线程会定期</code> merge。在 <code>数据库正常关闭（shutdown）</code> 的过程中，也会执行merge 操作。
如果能够将更新操作先记录在change buffer， <code>减少读磁盘</code> ，语句的执行速度会得到明显的提升。而且，数据读入内存是需要占用 buffer pool 的，所以这种方式还能够 <code>避免占用内存 </code>，提高内存利用率。
<code>唯一索引的更新就不能使用change buffer</code> ，实际上也只有普通索引可以使用。
如果要在这张表中插入一个新记录(4,400)的话，InnoDB的处理流程是怎样的？
<h2 id="113-change-buffer的使用场景">11.3 change buffer的使用场景</h2>
<ol>
<li>普通索引和唯一索引应该怎么选择？其实，这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，建议你尽量选择普通索引。</li>
<li>在实际使用中会发现，普通索引和 change buffer 的配合使用，对于数据量大的表的更新优化还是很明显的。</li>
<li>如果所有的更新后面，都马上伴随着对这个记录的查询，那么你应该关闭change buffer 。而在其他情况下，change buffer都能提升更新性能。</li>
<li>由于唯一索引用不上change buffer的优化机制，因此如果业务可以接受，从性能角度出发建议优先考虑非唯一索引。但是如果"业务可能无法确保"的情况下，怎么处理呢？
<ul>
<li>首先，业务正确性优先。我们的前提是“业务代码已经保证不会写入重复数据”的情况下，讨论性能问题。如果业务不能保证，或者业务就是要求数据库来做约束，那么没得选，必须创建唯一索引。这种情况下，本节的意义在于，如果碰上了大量插入数据慢、内存命中率低的时候，给你多提供一个排查思路。</li>
<li>然后，在一些“ 归档库 ”的场景，你是可以考虑使用唯一索引的。比如，线上数据只需要保留半年，然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率，可以考虑把表里面的唯一索引改成普通索引。</li>
</ul>
</li>
</ol>
<h1 id="12-其它查询优化策略">12. 其它查询优化策略</h1>
<h2 id="121-exists-和-in-的区分">12.1 EXISTS 和 IN 的区分</h2>
问题：
不太理解哪种情况下应该使用 EXISTS，哪种情况应该用 IN。选择的标准是看能否使用表的索引吗？
回答：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/04e5d7d124f24a1eb952c3a637fbc590~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=yn5SqDVUFtJE%2BvDLmSV74OgmoNU%3D">
<h2 id="122-count与count具体字段效率">12.2 COUNT(*)与COUNT(具体字段)效率</h2>
问：在 MySQL 中统计数据表的行数，可以使用三种方式： SELECT COUNT(*) 、 SELECT COUNT(1) 和 SELECT COUNT(具体字段) ，使用这三者之间的查询效率是怎样的？
答：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/d91c3f3812f946a4897c3d519f52ac2e~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=dE8rABzUEsM9V%2F%2F%2BQB%2BEK4ryedQ%3D">
<h2 id="123-关于select">12.3 关于SELECT(*)</h2>
在表查询中，建议明确字段，不要使用 * 作为查询的字段列表，推荐使用SELECT <字段列表> 查询。原因：
① MySQL 在解析的过程中，会通过查询数据字典将"*"按序转换成所有列名，这会大大的耗费资源和时间。
② 无法使用覆盖索引
<h2 id="124-limit-1-对优化的影响">12.4 LIMIT 1 对优化的影响</h2>
针对的是会扫描全表的 SQL 语句，如果你可以确定结果集只有一条，那么加上 LIMIT 1 的时候，当找到一条结果的时候就不会继续扫描了，这样会加快查询速度。
如果数据表已经对字段建立了唯一索引，那么可以通过索引进行查询，不会全表扫描的话，就不需要加上 LIMIT 1 了。
<h2 id="125-多使用-commit">12.5 多使用 COMMIT</h2>
只要有可能，在程序中尽量多使用 COMMIT，这样程序的性能得到提高，需求也会因为 COMMIT 所释放的资源而减少。
COMMIT 所释放的资源：
<ul>
<li>回滚段上用于恢复数据的信息</li>
<li>被程序语句获得的锁</li>
<li>redo / undo log buffer 中的空间</li>
<li>管理上述 3 种资源中的内部花费</li>
</ul>
<h1 id="13-淘宝数据库主键如何设计的">13. 淘宝数据库，主键如何设计的？</h1>
聊一个实际问题：淘宝的数据库，主键是如何设计的？
某些错的离谱的答案还在网上年复一年的流传着，甚至还成为了所谓的MySQL军规。其中，一个最明显的错误就是关于MySQL的主键设计。
大部分人的回答如此自信：用8字节的 BIGINT 做主键，而不要用INT。 <code>错 </code>！
这样的回答，只站在了数据库这一层，而没有 <code>从业务的角度</code> 思考主键。主键就是一个自增ID吗？站在 2022年的新年档口，用自增做主键，架构设计上可能 <code>连及格都拿不到</code> 。
<h2 id="131-自增-id-的问题">13.1 自增 ID 的问题</h2>
自增ID做主键，简单易懂，几乎所有数据库都支持自增类型，只是实现上各自有所不同而已。自增ID除了简单，其他都是缺点，总体来看存在以下几方面的问题：
<ol>
<li>
可靠性不高
存在自增ID回溯的问题，这个问题直到最新版本的MySQL 8.0才修复。
</li>
<li>
安全性不高
对外暴露的接口可以非常容易猜测对应的信息。比如：/User/1/这样的接口，可以非常容易猜测用户ID的值为多少，总用户数量有多少，也可以非常容易地通过接口进行数据的爬取。
</li>
<li>
性能差
自增ID的性能较差，需要在数据库服务器端生成。
</li>
<li>
交互多
业务还需要额外执行一次类似 last_insert_id() 的函数才能知道刚才插入的自增值，这需要多一次的网络交互。在海量并发的系统中，多1条SQL，就多一次性能上的开销。
</li>
<li>
**局部唯一性 **
最重要的一点，自增ID是局部唯一，只在当前数据库实例中唯一，而不是全局唯一，在任意服务器间都是唯一的。对于目前分布式系统来说，这简直就是噩梦。
</li>
</ol>
<h2 id="132-业务字段做主键">13.2 业务字段做主键</h2>
为了能够唯一地标识一个会员的信息，需要为会员信息表设置一个主键。那么，怎么为这个表设置主键，才能达到我们理想的目标呢？这里我们考虑业务字段做主键。
表数据如下：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/abe0f0192cc4456eaa00590c66035224~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=aUe%2FQJHm5VhD2tlg0w%2B7r09DAW0%3D">
在这个表里，哪个字段比较合适呢?
<ul>
<li>选择卡号（cardno）</li>
</ul>
会员卡号（cardno）看起来比较合适，因为会员卡号不能为空，而且有唯一性，可以用来标识一条会员记录。
<pre><code class="language-mysql">mysql> CREATE TABLE demo.membermaster
-> (
-> cardno CHAR(8) PRIMARY KEY, -- 会员卡号为主键
-> membername TEXT,
-> memberphone TEXT,
-> memberpid TEXT,
-> memberaddress TEXT,
-> sex TEXT,
-> birthday DATETIME
-> );
Query OK, 0 rows affected (0.06 sec)
</code></pre>
不同的会员卡号对应不同的会员，字段“cardno”唯一地标识某一个会员。如果都是这样，会员卡号与会员一一对应，系统是可以正常运行的。
但实际情况是，会员卡号可能存在重复使用的情况。比如，张三因为工作变动搬离了原来的地址，不再到商家的门店消费了（退还了会员卡），于是张三就不再是这个商家门店的会员了。但是，商家不想让这个会员卡空着，就把卡号是“10000001”的会员卡发给了王五。
从系统设计的角度看，这个变化只是修改了会员信息表中的卡号是“10000001”这个会员信息，并不会影响到数据一致性。也就是说，修改会员卡号是“10000001”的会员信息，系统的各个模块，都会获取到修改后的会员信息，不会出现“有的模块获取到修改之前的会员信息，有的模块获取到修改后的会员信息，而导致系统内部数据不一致”的情况。因此，从信息系统层面上看是没问题的。
但是从使用系统的业务层面来看，就有很大的问题了，会对商家造成影响。
比如，我们有一个销售流水表（trans），记录了所有的销售流水明细。2020 年 12 月 01 日，张三在门店购买了一本书，消费了 89 元。那么，系统中就有了张三买书的流水记录，如下所示：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/26ec2701993f4c6e93fd2d08f982ed3b~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=aPRfGXEDuEKp53364nfO3I4hkVU%3D">
接着，我们查询一下 2020 年 12 月 01 日的会员销售记录：
<pre><code class="language-mysql">mysql> SELECT b.membername,c.goodsname,a.quantity,a.salesvalue,a.transdate
-> FROM demo.trans AS a
-> JOIN demo.membermaster AS b
-> JOIN demo.goodsmaster AS c
-> ON (a.cardno = b.cardno AND a.itemnumber=c.itemnumber);
+------------+-----------+----------+------------+---------------------+
| membername | goodsname | quantity | salesvalue | transdate |
+------------+-----------+----------+------------+---------------------+
| 张三 | 书 | 1.000 | 89.00 | 2020-12-01 00:00:00 |
+------------+-----------+----------+------------+---------------------+
1 row in set (0.00 sec)
</code></pre>
如果会员卡“10000001”又发给了王五，我们会更改会员信息表。导致查询时：
<pre><code class="language-mysql">mysql> SELECT b.membername,c.goodsname,a.quantity,a.salesvalue,a.transdate
-> FROM demo.trans AS a
-> JOIN demo.membermaster AS b
-> JOIN demo.goodsmaster AS c
-> ON (a.cardno = b.cardno AND a.itemnumber=c.itemnumber);
+------------+-----------+----------+------------+---------------------+
| membername | goodsname | quantity | salesvalue | transdate |
+------------+-----------+----------+------------+---------------------+
| 王五 | 书 | 1.000 | 89.00 | 2020-12-01 00:00:00 |
+------------+-----------+----------+------------+---------------------+
1 row in set (0.01 sec)
</code></pre>
这次得到的结果是：王五在 2020 年 12 月 01 日，买了一本书，消费 89 元。显然是错误的！结论：千万不能把会员卡号当做主键。
<ul>
<li>选择会员电话或身份证号</li>
</ul>
会员电话可以做主键吗？不行的。在实际操作中，手机号也存在被运营商收回，重新发给别人用的情况。
那身份证号行不行呢？好像可以。因为身份证决不会重复，身份证号与一个人存在一一对应的关系。可问题是，身份证号属于个人隐私，顾客不一定愿意给你。要是强制要求会员必须登记身份证号，会把很多客人赶跑的。其实，客户电话也有这个问题，这也是我们在设计会员信息表的时候，允许身份证号和电话都为空的原因。
所以，建议尽量不要用跟业务有关的字段做主键。毕竟，作为项目设计的技术人员，我们谁也无法预测在项目的整个生命周期中，哪个业务字段会因为项目的业务需求而有重复，或者重用之类的情况出现。
<blockquote>
经验：刚开始使用 MySQL 时，很多人都很容易犯的错误是喜欢用业务字段做主键，想当然地认为了解业务需求，但实际情况往往出乎意料，而更改主键设置的成本非常高。
</blockquote>
<h2 id="133-淘宝的主键设计">13.3 淘宝的主键设计</h2>
在淘宝的电商业务中，订单服务是一个核心业务。请问，订单表的主键淘宝是如何设计的呢？是自增ID 吗？
打开淘宝，看一下订单信息：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/b087b05ddbf745aaad06dd3a73fcd3a8~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=q0mw86YsDhe2gCSnM0qHbfh0m1A%3D">
从上图可以发现，订单号不是自增ID！我们详细看下上述4个订单号：
<pre><code class="language-mysql">1550672064762308113
1481195847180308113
1431156171142308113
1431146631521308113
</code></pre>
订单号是19位的长度，且订单的最后5位都是一样的，都是08113。且订单号的前面14位部分是单调递增的。
大胆猜测，淘宝的订单ID设计应该是：
<pre><code class="language-mysql">订单ID = 时间 + 去重字段 + 用户ID后6位尾号
</code></pre>
这样的设计能做到全局唯一，且对分布式系统查询及其友好。
<h2 id="134-推荐的主键设计">13.4 推荐的主键设计</h2>
非核心业务 ：对应表的主键自增ID，如告警、日志、监控等信息。
核心业务 ：<code>主键设计至少应该是全局唯一且是单调递增</code>。全局唯一保证在各系统之间都是唯一的，单调递增是希望插入时不影响数据库性能。
这里推荐最简单的一种主键设计：UUID。
UUID的特点：
全局唯一，占用36字节，数据无序，插入性能差。
认识UUID：
<ul>
<li>为什么UUID是全局唯一的？</li>
<li>为什么UUID占用36个字节？</li>
<li>为什么UUID是无序的？</li>
</ul>
MySQL数据库的UUID组成如下所示：
<pre><code class="language-mysql">UUID = 时间+UUID版本（16字节）- 时钟序列（4字节） - MAC地址（12字节）
</code></pre>
我们以UUID值e0ea12d4-6473-11eb-943c-00155dbaa39d举例：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/5636d45afec5447bb497be0fa9c6892e~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=Nk6bWxCfkO7P4zbz19H%2BR3wcY5Y%3D">
<pre><code>为什么UUID是全局唯一的？
</code></pre>
在UUID中时间部分占用60位，存储的类似TIMESTAMP的时间戳，但表示的是从1582-10-15 00：00：00.00 到现在的100ns的计数。可以看到UUID存储的时间精度比TIMESTAMPE更高，时间维度发生重复的概率降低到1/100ns。
时钟序列是为了避免时钟被回拨导致产生时间重复的可能性。MAC地址用于全局唯一。
<pre><code>为什么UUID占用36个字节？
</code></pre>
UUID根据字符串进行存储，设计时还带有无用"-"字符串，因此总共需要36个字节。
<pre><code>为什么UUID是随机无序的呢？
</code></pre>
因为UUID的设计中，将时间低位放在最前面，而这部分的数据是一直在变化的，并且是无序。
改造UUID
若将时间高低位互换，则时间就是单调递增的了，也就变得单调递增了。MySQL 8.0可以更换时间低位和时间高位的存储方式，这样UUID就是有序的UUID了。
MySQL 8.0还解决了UUID存在的空间占用的问题，除去了UUID字符串中无意义的"-"字符串，并且将字符串用二进制类型保存，这样存储空间降低为了16字节。
可以通过MySQL8.0提供的uuid_to_bin函数实现上述功能，同样的，MySQL也提供了bin_to_uuid函数进行转化：
<pre><code class="language-mysql">SET @uuid = UUID();
SELECT @uuid,uuid_to_bin(@uuid),uuid_to_bin(@uuid,TRUE);
</code></pre>
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/af89065b336047588ab9adf9f6cd214d~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=cQ6rNhpDaRRnkH8fD%2Fk8TuLrNpY%3D">
通过函数uuid_to_bin(@uuid,true)将UUID转化为有序UUID了。全局唯一 + 单调递增，这不就是我们想要的主键！
有序UUID性能测试
16字节的有序UUID，相比之前8字节的自增ID，性能和存储空间对比究竟如何呢？
我们来做一个测试，插入1亿条数据，每条数据占用500字节，含有3个二级索引，最终的结果如下所示：
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/9a363352d382441e882d07efcd7906ee~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=FovPiJxz6PdBVjH0BF44xpLXeHE%3D">
从上图可以看到插入1亿条数据有序UUID是最快的，而且在实际业务使用中有序UUID在 <code>业务端就可以生成</code> 。还可以进一步减少SQL的交互次数。
另外，虽然有序UUID相比自增ID多了8个字节，但实际只增大了3G的存储空间，还可以接受。
<blockquote>
在当今的互联网环境中，非常不推荐自增ID作为主键的数据库设计。更推荐类似有序UUID的全局唯一的实现。
另外在真实的业务系统中，主键还可以加入业务和系统属性，如用户的尾号，机房的信息等。这样的主键设计就更为考验架构师的水平了。
</blockquote>
如果不是MySQL8.0 肿么办？
手动赋值字段做主键！
比如，设计各个分店的会员表的主键，因为如果每台机器各自产生的数据需要合并，就可能会出现主键重复的问题。
可以在总部 MySQL 数据库中，有一个管理信息表，在这个表中添加一个字段，专门用来记录当前会员编号的最大值。
门店在添加会员的时候，先到总部 MySQL 数据库中获取这个最大值，在这个基础上加 1，然后用这个值作为新会员的“id”，同时，更新总部 MySQL 数据库管理信息表中的当前会员编号的最大值。
这样一来，各个门店添加会员的时候，都对同一个总部 MySQL 数据库中的数据表字段进行操作，就解决了各门店添加会员时会员编号冲突的问题。
<h1 id="最后">最后：</h1>
<blockquote>
“在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时刻再次相遇。”
<img src="https://p0-xtjj-private.juejin.cn/tos-cn-i-73owjymdk6/972bef3e71ba41e4829928ce2bc26ce7~tplv-73owjymdk6-jj-mark-v1:0:0:0:0:5o6Y6YeR5oqA5pyv56S-5Yy6IEAgUmFpbmJvd1NlYQ==:q75.awebp?policy=eyJ2bSI6MywidWlkIjoiNzUyNTMzNTY0NTY2OTUxIn0%3D&rk3s=e9ecf3d6&x-orig-authkey=f32326d3454f2ac7e96d3d06cdbb035152127018&x-orig-expires=1751522714&x-orig-sign=W%2FjiRQ9Vp4KuXTzc8zjid9Kc%2FYk%3D">
</blockquote> 
来源：https://www.cnblogs.com/TheMagicalRainbowSea/p/18961445

頁: [1]

琼殿技术论坛's Archiver

10-2 MySQL 索引优化与查询优化