本组技术团队共享MySQL索引和慢速查询优化教程

MySQL以其卓越的性能、低廉的成本和丰富的资源，成为绝大多数互联网公司首选的关系型数据库，虽然性能优良，但如何正确使用MySQL已成为开发工程师的必修课程。我们经常看到的要求，如掌握MySQL、SQL语句优化从工作描述和理解数据库原理，我们知道，应用系统，读写大约10:1的比例，和插入操作和更新操作很少会遇到性能问题，最多的，也是最容易出现问题，或一些复杂的查询操作，所以优化查询显然是重中之重。

自7月13日以来，我一直在优化美国集团核心业务系统部门的慢速查询。有十多个系统，积累了数百个慢查询，随着业务的日益复杂，遇到各种奇怪的事情，各种各样的奇妙。本文旨在说明数据库索引的原理以及如何在开发工程师的角度优化慢查询。

慢查询引发的思考

选择
计数（*）
从
任务
哪里
状态= 2
和operator_id = 20839
和operate_time > 1371169729
和operate_time＜1371174603
和类型= 2；
系统用户反应函数越来越慢，所以工程师发现上面的SQL。

而且对查找我感兴趣，SQL需要优化，把每个字段加索引

我很惊讶地问为什么每个字段都需要索引。

将查询字段添加到索引将更快，工程师充满信心。

这种情况下可以建立一个共同的指标，因为它是最左前缀匹配，所以operate_time需要放在最后一位，和其他相关的问题需要被带到一个综合评价。

联合指数最左边前缀匹配综合评价工程师禁不住陷入了思考。

在大多数情况下，我们知道索引可以提高查询的效率，但是我们应该如何建立索引呢索引的顺序是什么许多人只知道它，事实上，理解这些概念并不难，指数的原理远比想象的复杂。

MySQL索引原理

指数的目的

索引的目的是提高查询效率。它可以和字典相似。如果我们想查找单词如果你没有索引，你可能需要阅读所有的单词来找出你想要什么，如果我想找到以M开头的单词或者从Ze开始的话呢你认为如果你没有索引，它就不能做吗

指数原理

除了字典，生活中随处可见索引的例子，例如火车站、书籍等等，它们都有同样的原理。他们希望通过缩小他们想要得到的数据的范围来获得最终结果，并将随机事件变为连续事件，也就是说，我们总是以同样的方式锁定数据。

数据库是相同的，但显然要复杂得多，因为不仅要面对等价的查询和范围查询（>，<，in，in），模糊查询（like），和查询（OR）等等。数据库应该选择什么样的方式来处理所有的问题让我们回顾一下字典的例子。我们能把数据分成若干部分，然后分段查询吗最简单的如果1000个数据，1到100分为第一段，101到200分为第二段，201到300分为第三部分。因此，我们可以查找第二百五十个数据并找出第三个片段，这样我们就可以一次消除无效数据，但是如果它是1000万的记录，有多少部分更好呢有一点算法的基础学生会认为与外膝体平均复杂性搜索树和具有良好的查询性能。但在这里我们忽略了一个关键的问题，复杂的模型是基于每一次相同的操作成本考虑数据库实现存储在磁盘上更复杂的数据，并在为了提高性能，和每个部分的数据读到内存中来计算的，因为我们知道，磁盘访问的成本大约是十万倍的内存访问，所以一个简单的搜索树是很难满足复杂的应用场景。

IO盘与读

前面提到的磁盘访问，所以在这里简要介绍IO和磁盘数据的读，是机械运动的，每一个读书的时间数据可以分为寻道时间和旋转等待时间，三部分的传输时间，寻找时间指的是磁臂移动到指定磁道所需的时间在一般情况下，主流磁盘旋转延迟小于5ms；我们经常听到磁盘的速度，如磁盘7200，表示每分钟转7200次，也就是说1转120次秒，旋转延迟是1 / 120 / 2 = 4.17ms；传输时间从磁盘或磁盘写数据的读取，通常在零点几毫秒，相比前两年的时间可以忽略不计。n一个磁盘的访问时间，一个IO磁盘时间约等于5 + 4.17 = 9ms，听起来不错，但你知道500 MIPS机可以每秒执行5亿条指令，因为指令取决于电气性能，换句话说一个IO的执行时间可以执行40万条指令十万、对亿万、千万级数据的数据库，每9毫秒，显然是一个灾难。下面的图是一个可供参考的计算机硬件延迟对比图：
考虑到磁盘IO很高，计算机操作系统做了一些优化，当一个IO，不仅当前磁盘地址的数据，但数据读取到相邻的内存缓冲区，因为当地的读数原理告诉我们，当计算机访问一个地址的数据，相邻的数据很快被访问。每个数据读取IO被称为一个页面（page）。多少数据的特定页面的操作系统一般是4K或8K，那就是，当我们读到的数据在一个页面，一个IO是实际发生的。这一理论对索引数据结构设计很有帮助。

索引数据结构

在前面讲生命索引的例子中，索引数据库的基本原理、复杂性以及操作系统的知识，目的是让大家知道任何数据结构都不只是发生。它会有背景和使用场景，我们现在总结一下，我们需要这样的数据结构，可以做什么，其实很简单，那就是：每个搜索数据的磁盘IO控制数量非常小，最好是一个恒定的大小。所以我们认为如果一个高度可控的多路径搜索树能满足需要吗这样，B+树就应运而生了。

对B+树的详细解读
上图是一个B+树和B+树的定义可以在B+树发现，这里只说一些关键的，浅蓝的区域我们称之为一个磁盘块，我们可以看到每个磁盘块包含若干个数据项（图中蓝色部分）和指针（黄色显示），如磁盘块1包含17个数据项和35，P1，P2和P3包含指针，P1的磁盘块小于17，P2说17和35的磁盘块之间，P3说超过35个磁盘块。在叶节点存在真实的数据：3, 5, 9，10, 13, 15，28, 29, 36，60, 75, 79，90, 99。非叶子节点不存储实际数据只存储数据项，指导搜索方向，如17和35，这在数据表是不真实的。

B+树的查找过程

如图所示，如果你想找到数据项29，然后1个磁盘块从磁盘加载到内存中，然后一个IO内存两检索出29 17和35之间，锁片1 P2磁盘存储器指针，因为时间很短（相对于磁盘IO）可以忽略，通过1块P2磁盘地址指针3个磁盘块从磁盘加载到内存中，二IO，29之间的26和30，锁定磁盘块3 P2的指针，8个磁盘块加载到内存的指针，IO的第三次，同时在记忆中搜索发现的两29、查询的结束，共三次IO。事实是，对B+树的3层可以代表数以百万计的数以百万计的数据，如果数据的搜索只需要日稀土IO，提高性能将是巨大的，如果没有指数，每一个数据项到一个IO，你需要总共一百万个IO，显然成本非常高。

B+树的性质

1。通过以上的分析，我们知道，IO数量取决于B +高度H的数量，假设数据表中的数据为n，大量的磁盘块的每个数据项M，H =（M + 1）n，当数据量N，M是大的，小的H；M =磁盘块的大小和数据项的大小，磁盘块的大小是一个数据页的大小是固定的，如果空间数据项目占比较小，更多的数据项的数目，这树的高度越低。这就是为什么每一个数据项的索引字段，尽可能小，如int 4字节，一半少一点，比bigint8字节。这就是为什么B+树需要真实的数据被放置到叶节点代替内部节点。当内部节点被放置时，磁盘块的数据项将显著减少，导致树的增加，当数据项等于1时，它将退化成一个线性表。

2。items of data when the b+ tree data structure is complex, such as (name, age, sex) when the b+ number is in accordance with the order from left to right to build a search tree, such as (three, 20, F) when the data retrieval, b+ tree will be determined search the next step in the direction of the priority name, if name age and sex respectively in the same comparison, finally get the retrieval data; but when (20, F) that is not the name data to the b+ tree, do not know the next step to check which node, because when you build a search tree is name the first is the factor, must first according to name to search to know where to go next query.For example, when (Zhang San, F) to retrieve this data, b+ tree, name can be used to specify a search 方向，但缺少一个年龄域，所以只有名字是张三个数据才被发现，那么，性别是f数据，这是一个非常重要的属性，左边的匹配特征指数。

慢查询优化

MySQL索引原理比较枯燥，你只需要有一个感性的知识，不需要非常透彻地理解。让我们回顾一下慢查询的开始，理解索引的原理，你认为呢首先，总结了指标的基本原理。

标引的几个原则

1。左前缀匹配原理，非常重要的原理，mysql本来就对，直到遇到范围查询（> 3和d＝4（A，B，如果C，D）建立顺序索引，D索引不被使用，如果建立（A，B，D，C））。可以使用索引，a，b，d顺序可以调整。

2 =在和可以是无序的，例如，A = 1和B = 2和C = 3，建立（A，B，C）索引可以是任意的顺序，MySQL查询优化器将帮助您优化索引形式。

三.选择高区别列为指标，判别公式计算（不同的COL） /计数（*），表示字段不重复的比例，记录我们扫描数目少的比例越大，1是唯一的主要区别，以及一些国家，性别字段可能在大数据区面临毕业是0，那有人会问，这个比例是怎样的体验对于不同的场景，这个值也是很难确定的。一般来说，我们需要0.1以上的连接字段，也就是说，平均1个扫描记录为10个。

4。列的索引不能参与计算，保持柱净化，如from_unixtime（create_time = '2014-05-29）不能用于索引，原因很简单，B+树存储在数据表中字段的值，但需要搜索，所有元素都是用来比较的功能，显然成本太大。因此，应当书面
create_time = unix_timestamp（'2014-05-29）；
5。尽量扩展索引，不要创建一个新索引。例如，表中已经有索引，现在添加了（a，b）索引，所以只需要修改原始索引。

返回到慢查询的开始

根据匹配原则，左，在索引的SQL语句应结合现状，operator_id，类型指数，operate_time状态，operator_id，型；订单是可以逆转的，所以我会说，找到所有相关的查询表，将是一个全面的分析；

例如，有一个查询如下所示
从状态= 0和类型= 12限制10的任务中选择*；
从状态= 0的任务中选择计数（*）；
那么指数（地位、类型、operator_id，operate_time）是非常正确的，因为它可以覆盖所有的情况。这是用最左匹配索引的原理

查询优化工件-解释命令

我相信你不熟悉解释命令。你可以参考官方网站解释输出的具体用法和字段含义。这里我们需要强调的是，行是核心索引。大多数行小句必须执行得很快（例外，下面），所以优化语句基本上是行的优化。

慢速查询优化的基本步骤

0。第一次看真的太慢了，注意设置sql_no_cache

1.where条件的单表查询，锁定最低收益记录表。这句话的意思是将在查询语句表。从表返回的最小记录数将开始查找。单个表的每个字段分别查询，以查看哪个字段具有最高的划分程度。

2.explain看看执行计划以1的预期一致（从表不锁定记录）

通过SQL语句的极限形式的3.order让表先看看

4。理解业务方的使用场景

参考建筑指数5的几个原则。索引中添加索引。

6。结果与0次分析的期望不一致。

几个缓慢的查询案例

下面的示例详细解释了如何分析和优化慢查询

复杂的语句

在许多情况下，我们编写SQL只是为了实现函数。这只是第一步。不同的句子写作方法在效率上本质上是不同的。这就要求我们对MySQL的执行计划和索引原理有一个清晰的了解。请看下面的语句。
选择
不同的cert.emp_id
从
cm_log CL
内部联接
（
选择
emp.id作为emp_id，
emp_cert.id作为cert_id
从
员工EMP
左连接
emp_certificate emp_cert
在emp.id = emp_cert.emp_id
哪里
EMP。is_deleted = 0
CERT）
（上
cl.ref_table = 'employee
和cl.ref_oid = cert.emp_id
）
（或
cl.ref_table = 'empcertificate
和cl.ref_oid = cert.cert_id
）
哪里
cl.last_upd_date > = '2013-11-07 15:03:00
和cl.last_upd_date <= '2013-11-08 16:00:00；
0。第一次运行，53记录1.87秒，没有聚合语句，更慢
53行（1.87秒）
1.explain
+ -- + + + + ------------- ------------ ------- --------------------------------- + ----------------------- + --------- + ------------------- ------- -------------------------------- + + +
我select_type表| | | |型possible_keys关键key_len | | | | REF |行|额外|
+ -- + + + + ------------- ------------ ------- --------------------------------- + ----------------------- + --------- + ------------------- ------- -------------------------------- + + +
| 1 |初级| CL | |范围cm_log_cls_id，idx_last_upd_date idx_last_upd_date | | 8 |空| 379 |使用；使用临时|
| 1 |初级| |所有空空空| | | |空| 63727 |使用；使用连接缓冲|
| 2 |衍生| EMP |所有|零零零零| | | | 13317 |使用|
| 2 |衍生| emp_cert REF emp_certificate_empid emp_certificate_empid | | | | 4 | meituanorg.emp.id | 1 |使用索引|
+ -- + + + + ------------- ------------ ------- --------------------------------- + ----------------------- + --------- + ------------------- ------- -------------------------------- + + +
简要介绍了实施方案，第一个MySQL扫描cm_log根据idx_last_upd_date索引表得到379条记录；然后63727记录的查找表扫描，分为两个部分，来源说，表结构，没有桌子，可以简单的理解为一个语句的结果集的形式，在ID声明said.derived2表明ID = 2查询构造虚拟表，返回63727条记录数。让我们看看ID = 2声明做什么写回如此庞大的数据量，第一个完整的雇员表13317记录表扫描，然后根据相关指标emp_certificate_empid emp_certificate表行= 1，每个协会只锁定一个R表效率高。收购完成后，379条记录的cm_log与规则相关。它可以从执行看到太多的返回数据，大多数数据恢复是不cm_log，因为cm_log只锁定379的记录。

如何优化呢你可以看到，我们要做的cm_log运行后加入的，所以我们可以做之前和cm_log加入该语句的仔细分析不难发现，其基本思想是，如果cm_log ref_table是empcertificate相关emp_certificate，如果ref_table是员工相关员工表，我们可以分为两个部分，并用接头连接，注意这里的工会，而工会都因为有得到原始记录清晰，工会才有这个功能。如果在原句没有不同，它不需要权衡，所以我们可以直接使用联盟所有，因为使用联盟需要大量的行动，这将影响SQL性能。

优化语句如下所示
选择
emp.id
从
cm_log CL
内部联接
员工EMP
在cl.ref_table = 'employee
和cl.ref_oid = emp.id
哪里
cl.last_upd_date > = '2013-11-07 15:03:00
和cl.last_upd_date <= '2013-11-08 16:00:00
和emp.is_deleted = 0
联盟
选择
emp.id
从
cm_log CL
内部联接
emp_certificate EC
在cl.ref_table = 'empcertificate
和cl.ref_oid = ec.id
内部联接
员工EMP
在emp.id = ec.emp_id
哪里
cl.last_upd_date > = '2013-11-07 15:03:00
和cl.last_upd_date <= '2013-11-08 16:00:00
和emp.is_deleted = 0
2。不需要了解商业现场，只需要经过改革的声明和经过改革的声明就能保持结果一致。

三.可以满足现有索引，而不需要构建索引。

4。用改造后的句子的实验，只有10ms已减少近200倍！
+ -- + + + + -------------- ------------ -------- --------------------------------- + ------------------- + --------- + ----------------------- ------ ------------- + + +
我select_type表| | | |型possible_keys关键key_len | | | | REF |行|额外|
+ -- + + + + -------------- ------------ -------- --------------------------------- + ------------------- + --------- + ----------------------- ------ ------------- + + +
| 1 |初级| CL | |范围cm_log_cls_id，idx_last_upd_date idx_last_upd_date | | 8 |空| 379 |使用|
| 1 |初级| EMP eq_ref初级| | | | 4 | meituanorg.cl.ref_oid | 1 |使用|
| 2 |联盟| CL | |范围cm_log_cls_id，idx_last_upd_date idx_last_upd_date | | 8 |空| 379 |使用|
| 2 |联盟| EC | | eq_ref小学，emp_certificate_empid初级| | 4 | meituanorg.cl.ref_oid | 1 | |
| 2 |联盟| EMP eq_ref初级| | | | 4 | meituanorg.ec.emp_id | 1 |使用|
|空|结合的结果，所有的零| | | | |空|空|空| |
+ -- + + + + -------------- ------------ -------- --------------------------------- + ------------------- + --------- + ----------------------- ------ ------------- + + +
53行（0.01秒）
明确的应用场景

这个例子的目的是推翻我们对列划分的认识。一般来说，我们认为索引越高，就越容易锁定更少的记录。但在某些特殊情况下，这一理论有局限性。
选择
*
从
stage_poi SP
哪里
sp.accurate_result = 1
（和
sp.sync_status = 0
或sp.sync_status = 2
或sp.sync_status = 4
）；
0。先看跑多长时间，951秒6.22秒数据，真慢。
951行集（6.22秒）
1。首先解释，行达到361万，type =所有都表示它是全表扫描。
+ -- + + + + ------------- ------- ------ --------------- + ------ + --------- + ------ --------- ------------- + + +
我select_type表| | | |型possible_keys关键key_len | | | | REF |行|额外|
+ -- + + + + ------------- ------- ------ --------------- + ------ + --------- + ------ --------- ------------- + + +
| 1 |简单| SP |所有|零零零零| | | | 3613155 |使用|
+ -- + + + + ------------- ------- ------ --------------- + ------ + --------- + ------ --------- ------------- + + +
2。所有字段都用于返回记录的数量，因为单表查询0完成了951。

三.尽可能让解释行接近951。

看accurate_result = 1号
select count（*），通过accurate_result从stage_poi组accurate_result；
---------- ----------------- + + +
|计数（*）accurate_result | |
---------- ----------------- + + +
| 1023 | - 1 |
| 2114655 | 0 |
| 972815 | 1 |
---------- ----------------- + + +
我们看到的accurate_result场之间区别的一个很低的程度，整个表只有三个值-1,0,1，和指数不会锁在一个很小的数据量。

再看看sync_status场
select count（*），sync_status从stage_poi组sync_status；
---------- ------------- + + +
|计数（*）sync_status | |
---------- ------------- + + +
| 3080 | 0 |
| 3085413 | 3 |
---------- ------------- + + +
同样的区别也很低，根据理论，不适合索引。

对这个问题的分析，它来到这个表不能优化的两列的结论，区分度很低，甚至与指数只能适应这种情况，这是很难做到的通用的优化，如sync_status 0, 3分布很平均，然后锁定记录是1亿级

4。查找业务方进行通信，查看场景的使用情况。业务方使用此SQL语句每隔五分钟扫描符合条件的数据。处理后的sync_status场改到1、五分钟，符合条件的记录数不是太多，1000左右。在了解业务情况，优化SQL简单，因为业务方面保证数据的不平衡。如果添加索引，可以过滤掉不需要的大部分数据。

5。在建立索引规则的基础上，使用下列语句建立索引
修改表stage_poi添加索引idx_acc_status（accurate_result，sync_status）；
6。观察到预期的结果，发现只有200毫秒是需要的，这是超过30倍的速度。
952行（0.20秒）
我们将回顾分析过程，单表查询优化是比较好的，大部分时间只需要现场条件在哪里与规则和指数一致，如果只有大脑没有优化，显然有些歧视是非常低的，不应该添加索引列会在指数增加，这将插入和更新的性能受到严重影响，也可能影响其他查询。因此，我们采用第四步调整使用场景SQL非常关键。只有当我们知道这个业务场景时，才能帮助我们更好地分析和优化查询语句。

无法优化语句

选择
C.id，
C.name，
c.position，
C.sex，
c.phone，
c.office_phone，
c.feature_info，
c.birthday，
c.creator_id，
c.is_keyperson，
c.giveup_reason，
c.status，
c.data_source，
from_unixtime（c.created_time）作为created_time，
from_unixtime（c.last_modified）作为last_modified，
c.last_modified_user_id
从
接触C
内部联接
contact_branch CB
在cb.contact_id入境=
内部联接
branch_user埠
在cb.branch_id = bu.branch_id
和bu.status在（
1，
2）
内部联接
org_emp_info OEI
在oei.data_id = bu.user_id
和oei.node_left > = 2875
和oei.node_right < = 10802
和oei.org_catery = - 1
顺序
c.created_time DESC LIMIT 0，
10；
或几步

0。首先看这个语句运行了多长时间，10条记录为13秒，令人难以忍受。
10行（13.06秒）
1.explain
+ -- + + + + ------------- ------- -------- ------------------------------------- + ------------------------- + --------- + -------------------------- ------ ---------------------------------------------- + + +
我select_type表| | | |型possible_keys关键key_len | | | | REF |行|额外|
+ -- + + + + ------------- ------- -------- ------------------------------------- + ------------------------- + --------- + -------------------------- ------ ---------------------------------------------- + + +
| 1 |简单| OEI | | REF idx_catery_left_right，idx_data_id idx_catery_left_right | | 5 | const | 8849 |使用；使用临时用filesort |；
| 1 |简单|埠| |参考小学，idx_userid_status idx_userid_status | | 4 | meituancrm.oei.data_id | 76 |使用；使用索引|
| 1 |简单| CB | | REF idx_branch_id，idx_contact_branch_id idx_branch_id | | 4 | meituancrm.bu.branch_id | 1 | |
| 1 |简单| C eq_ref初级| | | | 108 | meituancrm.cb.contact_id | 1 | |
+ -- + + + + ------------- ------- -------- ------------------------------------- + ------------------------- + --------- + -------------------------- ------ ---------------------------------------------- + + +
从执行计划，MySQL首先检查扫描记录8849 org_emp_info表，然后用branch_user表关联指数branch_user，然后把contact_branch表索引contact_branch。最后，主键与联系人表关联。

行返回很少，不能看到任何异常。我们正在查看语句，我们发现后面有+限制组合的顺序，会不会太多因此，我们简化SQL，删除订单，并限制后面，看看有多少记录被用来整理它们。
选择
计数（*）
从
接触C
内部联接
contact_branch CB
在cb.contact_id入境=
内部联接
branch_user埠
在cb.branch_id = bu.branch_id
和bu.status在（
1，
2）
内部联接
org_emp_info OEI
在oei.data_id = bu.user_id
和oei.node_left > = 2875
和oei.node_right < = 10802
和oei.org_catery = - 1

---------- + +
|计数（*）|
---------- + +
778878 | |
---------- + +
1行集（5.19秒）
发现在排序之前有778878条记录被锁定。如果按70万组结果排序，那将是灾难性的。难怪这么慢。我们可以改变我们的思想，首先，根据接触的created_time排序，然后加入会更快

所以下面的语句转换，和straight_join也可以用来优化

选择
C.id，
C.name，
c.position，
C.sex，
c.phone，
c.office_phone，
c.feature_info，
c.birthday，
c.creator_id，
c.is_keyperson，
c.giveup_reason，
c.status，
c.data_source，
from_unixtime（c.created_time）作为created_time，
from_unixtime（c.last_modified）作为last_modified，
c.last_modified_user_id
从
接触C
哪里
存在（
选择
一
从
contact_branch CB
内部联接
branch_user埠
在cb.branch_id = bu.branch_id
和bu.status在（
1，
2）
内部联接
org_emp_info OEI
在oei.data_id = bu.user_id
和oei.node_left > = 2875
和oei.node_right < = 10802
和oei.org_catery = - 1
哪里
cb.contact_id入境=
）
顺序
c.created_time DESC LIMIT 0，
10；
验证的影响预计将在1ms，上涨超过13000倍！

SQL
10行（0秒）
这个思想到目前为止已经完成，但我们在前面的分析中漏掉了一个细节，先排序再加入和加入第一次重新排序的理论开销是一样的，为什么升级这么多是因为有一个极限！实施过程大致是：根据指数排名前10的记录，MySQL，然后去加入过滤，当发现不是10，再到10，再加入，这一次显然在内部联接的数据过滤是非常多的，将是一场灾难，在极端的情况下，找到内心的一个数据每个MySQL也傻拿10，几乎通过数据表！

在不同参数的sql测试下
选择
sql_no_cache入境，
C.name，
c.position，
C.sex，
c.phone，
c.office_phone，
c.feature_info，
c.birthday，
c.creator_id，
c.is_keyperson，
c.giveup_reason，
c.status，
c.data_source，
from_unixtime（c.created_time）作为created_time，
from_unixtime（c.last_modified）作为last_modified，
c.last_modified_user_id
从
接触C
哪里
存在（
选择
一
从
contact_branch CB
内部联接
branch_user埠
在cb.branch_id = bu.branch_id
和bu.status在（
1，
2）
内部联接
org_emp_info OEI
在oei.data_id = bu.user_id
和oei.node_left > = 2875
和oei.node_right < = 2875
和oei.org_catery = - 1
哪里
cb.contact_id入境=
）
顺序
c.created_time DESC LIMIT 0，
10；

空集（2分18.99秒）
2分18.99秒！由于MySQL的嵌套循环机制，这种情况基本上是不可能优化的。

通过这个例子，我们可以看到并不是所有的句子都可以被优化，但是当我们优化时，当SQL用例返回时，我们将失去一些极端的情况，这将导致比以前更严重的后果。第二，不要过于自信，只针对具体情况进行优化，而忽略更复杂的情况。

慢查询的案例分析，以及上述只是几个典型案例。我们在优化过程中超过1000条，涉及16个加入废SQL，也见到了在线和离线数据库应用直接由慢查询差异导致的慢性死亡，也遇到varchar对等没写一个单引号马克，也遇到了笛卡尔积查询直接到图书馆从死亡。更多的情况下，实际上是经验的积累。如果我们熟悉查询优化器和索引的内部原理，那么分析这些案例就变得非常简单了。

写在后面

介绍了MySQL索引的原理和慢查询优化慢查询的方法，并对典型案例进行了详细分析，经过长时间的句子优化，发现任何数据库级优化都不值得应用系统的优化。这也是MySQL，它可以用来支持眉目传情 /脸谱网/淘宝的应用，但它可能不支持你的个人网站，将最新的流行语：便于查询，不易优化，写和珍惜！