概述

今天开发反馈同样的sql且数据量一致，但在综测环境需要140多秒，而在开发环境只需要1秒多，这是什么原因呢？下面一起来看看吧~

问题sql

<code>SELECT ty.IS_FIXATION AS isFixation,CASE WHEN ty.INSPECTION_RULES IS NOT NULL  AND ty.IS_INSPECTION = 'Y' THEN '未打卡' ELSE NULL  END AS inspectionStatus,
FROM t_ams_asset_card t LEFT JOIN T_AMS_ASSET_TYPE ty ON ty.TYPE_NO = t.ASSET_TYPE AND t.FINANCE_CODE = ty.ORG_CODE
LEFT JOIN hr_employee e ON t.USE_MAN = e.EMPLOYEE_CODE
WHERE t.ASSET_MODULE = 'OWN'  AND t.IS_DELETE = 'N'/<code>

对比：

思路：这种情况一般是没有索引或者索引失效导致。

1、对比执行计划

这里通过explain + sql查看执行计划

2、检查两边环境索引情况

可以发现两边环境都有索引，那应该就是某个索引失效了..

3、强制使用索引

这里试一下 force index(HR_EMPLOYEE_U1) ，发现强制使用索引也是失效的，在这里索引为什么会失效呢？

4、检查表存储引擎、表字段数据类型、表字段字符集

一般索引失效都是表的存储引擎、字段数据类型或者字符集不同导致走的隐性转换

<code>show full columns from hr_employee;
show full columns from t_ams_asset_card;/<code> 

5、修改字符集编码后测试

<code>SELECT
\tc.TABLE_SCHEMA '数据库',
\tc.TABLE_NAME '表',
\tc.COLUMN_NAME '字段',
\tc.COLUMN_DEFAULT '默认值',
\tc.IS_NULLABLE '是否为空',
\tc.DATA_TYPE '字段类型',
\tc.character_set_name '原字符集', 

\tc.collation_name '原排序规则',
\tCONCAT(
\t\t'ALTER TABLE ',
\t\tTABLE_SCHEMA,
\t\t'.',
\t\tTABLE_NAME,
\t\t' MODIFY COLUMN ',
\t\tCOLUMN_NAME,
\t\t' ',
\t\tCOLUMN_TYPE,
\t\t' CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci ',
\tCASE
\t\t\t
\t\t\tWHEN c.is_nullable = 'NO' THEN
\t\t\t'NOT NULL' ELSE 'NULL' 
\t\tEND,
\tCASE
\t\t\t
\t\t\tWHEN c.COLUMN_DEFAULT = '' THEN
\t\t\t' DEFAULT ''''' 
\t\t\tWHEN c.COLUMN_DEFAULT IS NULL THEN
\t\t\t' DEFAULT NULL' ELSE concat( ' DEFAULT ', '''', c.COLUMN_DEFAULT, '''' ) 
\t\tEND,
\t\t' comment ',
\t\t'''',
\t\tc.COLUMN_COMMENT,
\t\t'''',
\t\t';' 
) '修正SQL' 
FROM
\tinformation_schema.`COLUMNS` c 
WHERE
\ttable_name = 'hr_employee' and table_schema='lcp_db'
\tAND CHARACTER_SET_NAME = 'utf8';/<code>

6、再次查看执行计划

调整后发现已使用索引，且sql执行也在1秒内，满足需求。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~

閱讀更多 波波說運維 的文章

關鍵字: MySQL 字符集 索引