本文从遇到的问题出发，分析了tddl优化器、MySQL索引、分表拆分键的选择相关知识。最近由于应用需要进行多租户改造，对监控盯的较紧。发现了应用的一些问题，应用的hsf consumer成功率，不是一直都是100，偶尔出现99.99的情况，进一步查应用日志发现，是因为慢sql导致服务超时失败。
( select `iop_xxx_msg`.`id`, `iii_sss_msg`.`message_id`, `iii_sss_msg`.`title`, `iii_sss_msg`.`content`, `iii_sss_msg`.`id_seller`, `iii_sss_msg`.`id_user`, `iii_sss_msg`.`gmt_create`, `iii_sss_msg`.`gmt_modified`, `iii_sss_msg`.`is_read`, `iii_sss_msg`.`category`, `iii_sss_msg`.`sub_category`, `iii_sss_msg`.`description`, `iii_sss_msg`.`need_side_notice`, `iii_sss_msg`.`link_url`, `iii_sss_msg`.`btn_name`, `iii_sss_msg`.`gmt_create_l`, `iii_sss_msg`.`mobile_content`, `iii_sss_msg`.`tier`, `iii_sss_msg`.`requirement_id`, `iii_sss_msg`.`fk_template_id`, `iii_sss_msg`.`business_part`, `iii_sss_msg`.`business_id` from `iii_sss_msg_29` `iii_sss_msg` WHERE ( ( ( `iii_sss_msg`.`gmt_create` >= '2023-07-24 00:00:00' ) AND ( `iii_sss_msg`.`gmt_create` < '2023-07-31 15:46:45.684' ) AND (`iii_sss_msg`.`id_user` = 500173482096) AND (`iii_sss_msg`.`tier` IN ('S', 'A')) AND ( `iii_sss_msg`.`sub_category` IN (1000305, 1000306, 1000501, 1000502) ) ) OR ( (`iii_sss_msg`.`category` IN (10003, 10005)) AND ( `iii_sss_msg`.`gmt_create` >= '2023-07-24 00:00:00' ) AND ( `iii_sss_msg`.`gmt_create` < '2023-07-31 15:46:45.684' ) AND (`iii_sss_msg`.`id_user` = ***) AND ( `iii_sss_msg`.`sub_category` IN (1000305, 1000306, 1000501, 1000502) ) ) ) order by `iii_sss_msg`.`gmt_create` desc limit 0, 5)union all ...
语句较为复杂，概括来讲sql语句的含义是找到七天内某个商家的某几个类目或者tier='S' 的最近的五条消息。由iii_sss_msg表根据创建时间分了31张表，路由规则如下：<property name="tbRuleArray"> <value>"iii_sss_msg_" + getCalendar(#gmt_create,1_date,31#).get(Calendar.DAY_OF_MONTH)</value> </property>
所以该查询连接了七张表iii_sss_msg_29、iii_sss_msg_30....(该分表规则极不合理，本文之后分析)我们看看mybatis对应的xml文件是什么样的。<select id="selectByQuery" resultMap="webMsgResultMap" parameterType="map" > select <include refid="Base_Column_List" /> from iii_sss_msg where id_user = #{userId} <if test="startTime != null"> and gmt_create <![CDATA[>=]]> #{startTime} </if> <if test="endTime != null"> and gmt_create <![CDATA[<]]> #{endTime} </if> ...
发现mybatis对应的sql语句where条件的排序与我们最后看到的sql语句的并不一样。是有什么改变了这个语句？我们的应用使用了tddl，在mybatis生成了sql后还会被tddl更改，tddl的工作流程如下，在Matrix层会对mysql进行解析与优化。（详细的tddl知识请读者自行查阅相关知识）
问题解答了，是tddl改变了这个语句，目的是优化查询。那目的达到了吗？
发现该表有个名为idx_user的索引，该索引是gmt_create,id_user,category,sub_category四个字段的联合索引。这几个字段刚好都在上面慢sql的where条件中。看起来tddl调整sql语句的顺序是为了利用该索引。
发现用的索引并不是idx_user（gmt_create,id_user,category,sub_category），而是idx_uer_query（id_user,category）。看起来tddl自作多情了。那为什么mysql选择的是idx_user_query（id_user,category）索引呢？为了验证这个问题我们使用
force index（idx_user（gmt_create,id_user,
category,sub_category））强制使用idx_user索引。
对比两个执行计划发现，使用idx_uer_query（id_user,category）索引的扫描行数是13948，但是使用idx_user
（gmt_create,id_user,category,sub_category）
的索引的扫描行数是1552218，扫描行数是前者的100多倍！这个索引用了个寂寞，幸好mysql没听信tddl的谗言。那mysql怎么知道使用idx_user索引会更好？选择索引是优化器的工作。而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。优化器主要会根据以下条件考虑：1.查询语句中的条件：MySQL 会根据查询语句中的条件选择最合适的索引，以尽可能快地定位符合条件的行。如果查询条件包括多个列，那么可以考虑建立多列索引，以便在匹配时更高效。2.索引的选择性（基数）：MySQL 会根据索引的选择性来选择最合适的索引。选择性是指索引列中不同值的个数与表中记录总数的比值。选择性越高，索引的效率越高。3.索引的大小和数据类型：索引的大小和数据类型也会影响索引的选择。较小的索引通常比较大的索引效率更高，而数据类型的不同也会影响索引的效率。4.数据块的大小：MySQL 使用数据块（或称为页）来存储索引数据和表数据，数据块的大小也会影响索引选择。较小的数据块能够提高缓存的效率，并减少磁盘 I/O 操作的次数。5.索引的覆盖度：如果一个查询可以使用覆盖索引来满足，则 MySQL 通常会优先选择使用覆盖索引。覆盖索引是指查询语句中需要的列都包含在索引中，不需要再到表中读取数据。如果按照1、5点当然选择idx_user（gmt_create,id_user,category,sub_category）更好，但是第二点呢？SHOW INDEX FROM `iii_sss_msg_29`
发现idx_user（gmt_create,id_user,category,sub_category）的gmt_create列的基数为99933，idx_uer_query（id_user,category）的id_user的基数为286528优于前者。综合考虑，所以优化器选择idx_uer_query（id_user,category）索引。上面我们分析的两个索引的基数差距并不是很大（优化器也可能预估错误）,然而idx_user（gmt_create,id_user,category,sub_category）索引在查询语句中的条件中的匹配度跟高和使用索引idx_user（gmt_create,id_user,category,sub_category）可以避免排序（idx_user（gmt_create,id_user,category,sub_category）本身是索引，已经是有序的了，如果选择索引idx_user（gmt_create,id_user,category,sub_category）的话，不需要再做排序，只需要遍历），所以即使扫描行数多，也判定为代价更小。会有这样的情况发生吗？多次执行，看看其他分表的执行计划，发现优化器这次使用了idx_usery索引！tddl优化器和索引idx_user（gmt_create,id_user,category,sub_category）里应外合误使优化器选择了错误的索引。选择了一百多万的扫描行数的执行方案。
使用索引
idx_user（gmt_create,id_user,category,sub_category）需要执行995毫秒：
使用索引idx_uer_query（id_user,category）需要执行95毫秒：
这可能就是慢sql的原因了：tddl优化器选择了错误的索引。我们再来看看下面这个索引：
idx_user（gmt_create,id_user,category,sub_category）为什么建立这个索引？大概是因为业务需求，有以上的条件查询的语句较多。但是该索引合理吗？
上图是笔者画的idx_user（gmt_create,id_user,category,sub_category）索引的B+树结构图。可以看到B+树只维护第一列gmt_create的有序性，其他字段的有序性没有维护。由该表的分表分表规则可知iii_sss_msg_29的创建时间都在（2023-07-29 00:00:00-2023-07-29 23:59:59）之间。WHERE ( ( ( `iii_sss_msg`.`gmt_create` >= '2023-07-24 00:00:00' ) AND ( `iii_sss_msg`.`gmt_create` < '2023-07-31 15:46:45.684' )
可知若使用该索引，idx_user所有的叶子结点都会扫描一遍！之前强制使用该索引查询时扫描行数一百多万，主键id索引的基数三百多万，两者是同一量级。idx_user（gmt_create,id_user,category,sub_category）索引在上述sql的应用场景是不合理的，特别是在按创建时间的分表规则下。笔者将其改为idx_user（id_user,category,sub_category，gmt_create，is_read）(因为是否已读也常见于业务条件中，因此加上)。更改之后，在次查看sql语句的执行计划，发现这次优化器坚定的选择了idx_user（id_user,category,sub_category，gmt_create，is_read）索引。这次扫描行数只有一万多行。与idx_uer_query（id_user,category）索引相比，该索引还能减少回表次数。
mysql的索引不是刚建表的时候就能创建完全的。索引是为了加快查询数据，与业务场景强相关。所以索引要根据业务查询做相应的变化。不合理的索引反而会妨碍查询，误导优化器。iii_sss_msg表根据gmt_create进行分表，该拆分键是合理的吗？1.能够最大限度的实现数据均匀分布到每个物理分表上去，即能够实现负载均衡实现均匀拆分其实最好的就是自增的主键取模。但是可能主键不是自增，甚至不是数字就不一定能够实现绝对的均匀分布了。3.尽可能的实现所有的查询sql的where语句后都能够带上这个字段，如果做不到也要有方式能够路由到具体的物理表。查七天内某个商家的一些类目的消息是我们应用最常见的场景，但是iii_sss_msg消息表却根据gmt_create进行分表，频繁触发联表查询，每次查询要从七张表里面取数据，那如果以后要看一个月内的消息，那得从三十张表里面取数据。如此看来该拆分键极不合理。根据业务场景来看，按照id_user作为拆分键是更佳选择。（该改动较为费时，待后期排期解决QAQ）本文从遇到的问题出发，分析了tddl优化器、MySQL索引、分表拆分键的选择相关知识，以下是知识总结：1.tlld在Matrix层会对mysql进行解析与优化。2.选择索引是优化器的工作。而优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。优化器主要会根据以下条件考虑：查询语句中的条件、索引的选择性（基数）、索引的大小和数据类型、数据块的大小、索引的覆盖度。3.mysql优化器存在选错索引的可能性。对于优化器误判的情况，可以在应用端用force index来强行指定索引，也可以通过修改语句来引导优化器，还可以通过增加或者删除索引来绕过这个问题。4.拆分键的选择重点应该考虑：能够最大限度的实现数据均匀分布到每个物理分表上去、拆分键不可为空，必须要有索引、尽可能的实现所有的查询sql的where语句后都能够带上这个字段、要注意将相关联的一系列数据拆分到同一个表中。
