MySQL WHERE子句核心语法与性能优化指南：正确使用SELECT、UPDATE、DELETE及避免索引失效
WHERE子句必须依附于主查询语句：SELECT、UPDATE或DELETE
编写SQL查询时，一个常见的误区是认为WHERE可以独立运行。例如，直接执行WHERE id > 10 AND status = 'active'会导致MySQL报出ERROR 1064 (42000)语法错误。正确的理解是：WHERE子句是条件筛选的核心组件，但它必须完整地跟在SELECT ... FROM ...、UPDATE ... SET ...或DELETE FROM ...这些主语句之后，构成一个可执行的查询指令。
这种错误通常发生在以下场景：
- 快速编写或调试时，只关注了条件逻辑，遗漏了查询的主体结构。
- 在MySQL命令行或工具中，误将WHERE当作独立命令输入。
牢记：任何有效的条件查询都必须以完整的语句开始，WHERE仅负责在其中定义过滤规则。
字符串值必须使用单引号，数字与NULL无需引号
MySQL语法严格区分数据类型在查询中的表示方式。字段名和SQL关键字不加引号；字符串值必须用单引号' '包裹；而数字常量、NULL值则直接书写，无需任何引号。
错误使用引号会引发两类问题：一是直接语法错误，例如WHERE name = Alice（MySQL会将Alice解析为标识符）；二是更隐蔽的性能问题——隐式类型转换。当数字类型字段被写成WHERE id = '123'时，数据库需先将字符串'123'转换为数字，此过程会导致该字段上的索引无法被有效利用，在大数据量下严重拖慢查询速度。
参考以下正确与错误示例（针对users表）：
- ✅ 标准写法：
WHERE name = 'Alice' AND age > 25（字符串引号包裹，数字直接使用） - ❌ 语法错误：
WHERE name = Alice（缺少引号，Alice被视为列名） - ⚠️ 性能隐患：
WHERE id = '100'（数字加引号，可能引发索引失效）
判断NULL值必须使用IS NULL或IS NOT NULL运算符
NULL在SQL中表示“未知”或“不存在”，其逻辑比较具有特殊性。使用普通的等号=或不等号!=与NULL进行比较，结果均为UNKNOWN，而非TRUE或FALSE。因此，WHERE email = NULL无法筛选出email字段为空的记录。
处理NULL值的正确语法是使用专用的运算符：
WHERE email IS NULL（筛选字段为空的记录）WHERE email IS NOT NULL（筛选字段非空的记录）
需特别注意两点：第一，IS NULL是一个完整的运算符，不可拆分；第二，在IN()列表中包含NULL是无效的，例如WHERE status IN ('active', NULL)并不会匹配到status为NULL的行。
LIKE模糊查询的通配符使用与索引优化策略
LIKE操作符的性能关键在于通配符%的位置。当模式以%开头时（如LIKE '%son'），MySQL的B+Tree索引将无法执行有效的前缀匹配，优化器通常会放弃索引，转而进行全表扫描，导致查询性能急剧下降。
不同模式的性能影响对比：
- ✅ 索引有效：
WHERE name LIKE 'John%'（前缀匹配，可充分利用索引） - ❌ 索引失效：
WHERE name LIKE '%ohn%'或WHERE name LIKE '%hn'（前导通配符导致全表扫描） - ⚠️ 大小写敏感：默认校对规则下
LIKE不区分大小写。若字段字符集设置为utf8mb4_bin等二进制规则，则比较区分大小写。
若业务必须进行后缀匹配，建议考虑替代方案以规避性能瓶颈：例如为字段建立反向索引（存储反转后的字符串），或对于文本搜索需求，使用MySQL的全文索引（FULLTEXT）功能。
掌握WHERE子句的精髓，不仅在于语法正确，更需深入理解其与数据类型、三值逻辑（TRUE/FALSE/UNKNOWN）以及数据库索引机制的协同工作原理。细微的写法差异，可能直接影响查询结果的准确性、执行效率及系统的整体可维护性。
