SQL Server字符列CHECK约束为何未实现表筛选优化？

这个问题我之前也碰到过，本质是数据库优化器对不同类型CHECK约束的「理解能力」有差异，咱们一步步拆解清楚：

一、为啥数值ID的CHECK约束能正常过滤？ #

当你用数值范围（比如ID < 1000000）作为CHECK约束时，这类约束属于明确的区间型规则，优化器一眼就能看懂：

• 比如你查ID=1500000，优化器会直接对比三个表的区间：这个值既不在表a的<1000000里，也不在表c的>2000000里，所以直接跳过这俩表，只查表b。
• 这类约束是可被优化器用于谓词下推的，属于数据库优化器的「舒适区」操作。

二、为啥LIKE的CHECK约束就失效了？ #

换成name LIKE 'a%'这种模式匹配的约束，优化器就「懵」了，主要有两个原因：

1. LIKE约束无法被自动转成明确范围：虽然咱们人类知道name LIKE 'a%'等价于name >= 'a' AND name < 'b'（在常规ASCII排序规则下），但大多数数据库的优化器不会主动做这个转换。它没办法把查询条件name='bcd'和LIKE 'a%'做精确的逻辑推导——说白了，优化器的规则里没有把「等于bcd」和「以a开头」做互斥判断的逻辑。
2. 字符排序规则的不确定性：如果你的数据库用了特殊排序规则（比如大小写不敏感、区分重音），优化器会更谨慎。它没法100%确定'BCD'或者带重音的'àbcd'会不会被LIKE 'a%'匹配，干脆就不做过滤，直接扫所有表。

三、怎么解决这个问题？ #

要让优化器能正常过滤，得把LIKE约束换成明确的范围型CHECK约束，比如：

• 表a：CHECK (name >= 'a' AND name < 'b')
• 表b：CHECK (name >= 'b' AND name < 'c')
• 表c：CHECK (name >= 'c')

这样优化器就能像处理数值ID那样，把name='bcd'和各个表的范围对比，快速排除表a和表c，只查表b。

如果你必须保留LIKE约束来确保数据正确性，可以同时加上范围约束——数据库会优先用范围约束做优化，同时用LIKE约束保证数据符合要求。

内容的提问来源于stack exchange，提问作者Wison Ho