where中对索引列使用函数（如year()）或表达式（如price+10）会导致索引失效，应改写为范围查询或移除列上的计算，例如year(created_at)=2023→created_at>='2023-01-01' and created_at
WHERE里用YEAR()、DATE()等函数会直接让索引失效
MySQL无法对索引列执行函数后再比对，因为B+树索引存的是原始值，不是函数结果。哪怕created_at字段上有索引，WHERE YEAR(created_at) = 2023也会触发全表扫描。
正确做法是把函数逻辑“反向”挪到常量侧，改写为范围查询：
-
YEAR(created_at) = 2023→created_at >= '2023-01-01' AND created_at -
DATE(create_time) = '2023-10-01'→create_time >= '2023-10-01 00:00:00' AND create_time -
LEFT(name, 3) = 'abc'→name LIKE 'abc%'
注意BETWEEN写法容易出边界错误（含首含尾），推荐用>= + 更可控。
UPPER()、LOWER()这类字符串函数同样破坏索引
对索引列调用大小写转换函数，比如WHERE LOWER(email) = 'a@b.com'，会让email上的索引完全失效。
可行的替代路径有三条：
- 应用层统一存小写/大写，查询时保持一致（如都存
LOWER(email)，查也用小写） - MySQL 8.0+ 可建函数索引：
CREATE INDEX idx_email_lower ON users ((LOWER(email))) - 字段本身加
COLLATE utf8mb4_0900_as_cs并确保查询值带引号，避免隐式转换干扰
别依赖WHERE email COLLATE utf8mb4_general_ci = 'A@B.COM'——排序规则不等于索引可用性，仍可能走全表。
运算表达式如 price + 10 > 100 也会跳过索引
只要索引列出现在表达式左侧，比如price + 10 > 100或amount * 1.1 ，优化器就无法定位索引边界。
一律移项，让索引列单独出现在比较符一侧：
-
price + 10 > 100→price > 90 amount * 1.1 → <code>amount （建议预计算，避免每次除法）-
id * 2 = 100→id = 50
如果业务真需要动态系数，考虑冗余一个计算后字段（如final_price），再对其建索引。
CONVERT()和CAST()作用在索引列上等于主动放弃索引
显式类型转换和隐式转换一样危险。WHERE CAST(phone AS UNSIGNED) = 13800000000或CONVERT(age, CHAR)都会导致phone或age索引失效。
根本解法只有两个：
- 字段定义与查询参数严格一致：
phone是VARCHAR，就传'13800000000'；age是INT，就传18 - 若必须跨类型匹配（如手机号要支持+86前缀），提前在表里存标准化值（如
phone_normalized），并在该字段建索引
最常被忽略的是ORM框架传参时自动类型推断——Java的Long塞进VARCHAR字段，或Python的int传给字符串列，都会悄悄触发转换。
