and连接多条件时顺序不影响结果但影响可读性与性能；要求所有条件为真才返回记录，字符串需加引号，null参与比较会致结果为空，混合or时须用括号明确逻辑。
WHERE子句里用AND连多个条件，顺序不影响结果但影响可读性
SQL中AND是标准且最常用的多条件组合方式，它要求所有条件同时为真才返回记录。不需要额外括号包裹——除非混用OR或否定逻辑，否则WHERE a = 1 AND b > 5 AND c LIKE '%x%'这种写法天然成立。
常见错误是把AND写成逗号分隔（如WHERE a = 1, b > 5），这会直接报错：ERROR: syntax error at or near ","。另一个典型误用是混淆AND和OR优先级，比如想查“北京的男用户或上海的女用户”，却写成WHERE city = '北京' AND gender = '男' OR city = '上海' AND gender = '女'——表面看没问题，但实际因AND优先级更高，等价于(city = '北京' AND gender = '男') OR (city = '上海' AND gender = '女')，反而刚好是对的；真正危险的是漏括号导致逻辑反转，比如WHERE status = 'active' AND type = 'vip' OR level > 10，本意可能是“活跃VIP且等级>10”，结果却变成“活跃VIP”或“任意用户的等级>10”。
字符串匹配、空值、类型隐式转换是AND条件里最容易出错的三类场景
用AND串联条件时，看似简单，但以下情况会让结果意外为空：
-
name LIKE '%李%'和age >= 18同时存在时，如果name字段含大量NULL，那整行不会被选中——因为NULL LIKE '%李%'结果是UNKNOWN，而AND要求所有条件为TRUE，UNKNOWN不满足 -
status = '1'和created_at > '2023-01-01'连用时，若status是数字类型字段，而传入字符串'1'，某些数据库（如PostgreSQL）会拒绝隐式转换并报错operator does not exist: integer = text；MySQL可能悄悄转成功，但走不到索引 -
email IS NOT NULL AND email != ''看似稳妥，但有些数据库里空字符串''和NULL行为不一致，建议统一用TRIM(email) != ''防空白字符干扰
多个AND条件是否要加索引？看字段选择性和过滤顺序
数据库优化器一般会按统计信息自动选择索引字段顺序，但人为干预仍有价值。例如查询WHERE product_type = 'book' AND price BETWEEN 20 AND 50 AND in_stock = true，如果product_type只有3个取值（低选择性），而in_stock是布尔字段（50%分布），真正能快速过滤的是price范围——这时建复合索引应把price放前面：CREATE INDEX idx_products_price_type ON products (price, product_type, in_stock)。
注意：MySQL 8.0+ 支持索引跳跃扫描（skip scan），对某些前导列重复值高的场景有缓解，但不能替代合理设计。另外，LIKE带前导通配符（如LIKE '%abc'）的条件无法使用B-tree索引，放在AND链尾也无济于事。
用AND处理时间范围时，别忽略时区和边界值
写AND created_at >= '2024-01-01' AND created_at 比<code>BETWEEN更安全，因为BETWEEN是闭区间，容易在毫秒级时间戳上漏掉最后一刻数据。但更要小心的是时区：
- 如果数据库时区是UTC，而业务时间按东八区理解，
'2024-01-01'会被当成UTC时间，实际过滤的是北京时间2024-01-01 08:00:00之后的数据 - PostgreSQL中可用
AT TIME ZONE 'Asia/Shanghai'显式转换，如created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Asia/Shanghai' >= '2024-01-01' - SQLite没有原生时区支持，得靠应用层处理或存为本地时间字符串（不推荐）
复杂点往往不在AND语法本身，而在每个条件背后的值来源是否可靠、类型是否一致、时区是否对齐、空值是否被预期——这些细节一错，整个条件链就失效了。
