背景
最近业务反馈，列表查询速度过慢，需要优化。
到正式环境系统去验证，发现没筛选任何条件的情况下，查询需要三十多秒，而筛选了条件之后需要13秒。急需优化。
先说结论：连表用的字段编码方式不一致导致索引不可用。
SQL验证
1.本地运行项目，找到相应的查询接口，利用MbBatis Log插件获取到分页查询的SQL，拿到数据库去运行，18秒，好久。
2.而且，因为项目使用的是jeecgboot项目，分页在分页查询之后会先查询总数，拿查总数的SQL来验证。也是要13秒，太慢啦。
看看执行计划
3.从SQL来看，u表有用到主键id来做关联，照理说索引应该用主键才对，但执行计划显示并没有使用主键。尝试把u表相关的关联表去掉看看是不是这个表的原因。
4.速度大幅度提高，说明问题确实出现在u表相关的几个表。去看看u表的结构。索引是存在的，但却并没有用到，很奇怪。再看看编码方式。
5.再对比一下关联的hr表的sys_user_id字段
6.两个字段的编码方式不一样，尝试把u表的编码方式改成和hr表一致。再运行SQL。
7.速度提升不明显，再看看执行计划。
8.ud表好像也有点问题，索引类型不太正常，看了一下表结构，发现也是编码问题，顺便也改了（d表也有一样问题，也改了）。
9.看看分页查询的速度
10.这个速度还可以，再看看执行计划。索引的类型现在要么是eq_ref，要么是ref，并且能用主键的基本也是用主键，符合预期了。
修改前后执行计划对比
前
后
11.最后去系统体验，查询速度大概是3.6秒，相比一开始的30多秒，速度提升了七八倍。
分析
本来u表的数据量并不大，但其他表连接之后，数据量已经非常大了，u表的速度稍微慢一点都会很明显。而u表几乎是全表扫描，也就出现了整个接口速度很慢的场景。
想要继续调优，目前的打算是把一部分主查询没有用来筛选的字段拆分开，在外层先查出来再在主SQL里面用in查询。