SQL 零基础(五):LIKE ‘S%’ 为什么连小写 s 也抓?——聊聊替你做决定的排序规则起因是一道练习题:“查出 LastName 以 S 开头的运动员”。答案LIKE S%轻松通过。但复盘时冒出一个问题:这句会不会把小写 s 开头的也抓进来?一试,还真会。今天顺着这个侥幸答对的题,挖出背后替你做决定的那只手。一、LIKE 快速回顾:两枚通配符LIKE 做模糊匹配,全部本事就两个符号:通配符含义例子%任意长度的任意字符(包括零个)S%S 开头;%an%含 an;%erer 结尾_恰好一个任意字符M_y命中 May、Moy,不命中 MarrySELECT*FROMAthleteWHERELastNameLIKES%-- 姓氏 S 开头,113 人二、实验:它真的不分大小写跑个对照实验(你可以在任何 SQL Server 上复现):SELECT*FROMAthleteWHERELastNameLIKES%-- 大写 SSELECT*FROMAthleteWHERELastNameLIKEs%-- 小写 s两句结果一模一样。也就是说,和LIKE在这个数据库里压根不区分大小写:abc ABC判定为真。练习题里没翻车,纯属侥幸——这份数据的姓氏都是规范的大写开头。假如库里混着smith和Smith,而需求只要大写 S 的,这句就悄悄多抓了人。又是一个在这份数据上不会错 ≠ 逻辑上不会错的案例(本系列第三次出现这个句式了,重要的事情说三遍)。三、谁规定的不分大小写?——排序规则(Collation)大小写敏不敏感,不是 LIKE 的属性,也不是 SQL Server 的天性,而是由一个叫**排序规则(Collation)**的配置决定的。它是数据库给字符串怎么比较、怎么排序定的游戏规则:é 和 e 算不算一样?中文按拼音还是笔画排?大写小写算不算同一个字?——全是它管。排序规则的名字像密码,但拆开就懂:Chinese_PRC_CI_AS │ │ │ 语言区域 │ └─ AS Accent Sensitive,区分重音(é ≠ e) └─── CI Case Insensitive,不区分大小写 ★关键就看CI / CS这一段:CI(CaseInsensitive):大小写不敏感——中文环境安装 SQL Server 的默认值,这就是那只手CS(CaseSensitive):大小写敏感四、想区分大小写?COLLATE 现场改规则不用改数据库,查询里用COLLATE关键字临时切换规则,当场生效:SELECT*FROMAthleteWHERELastNameCOLLATELatin1_General_CS_ASLIKES%念作:“比较 LastName 时,临时改用 Latin1_General_CS_AS 这套区分大小写的规则”。这样小写 s 开头的就被排除了。这个知识点掌握到什么深度合适?知道有 Collation 这回事、知道 CI/CS 的含义、知道关键字叫 COLLATE——够了。规则的具体名字不用背,真实需求出现时查文档,一分钟的事。五、这一课真正值钱的部分比COLLATE 怎么写更重要的,是这个思维模型:你以为的默认行为,背后都有一个替你做决定的配置。大小写不敏感不是天经地义,是 CI 规则替你选的;查询结果看起来有序不是承诺,是聚集索引碰巧的(第二篇);按名字分组没出错不是正确,是数据碰巧不重名(第四篇)。所以遇到任何它怎么就这样了?“的时刻,别停在哦,默认就这样”,多问一句:这个默认是谁定的?在哪能改?什么时候会变?这三问,就是初学者和工程师的分水岭。一句话带走LIKE 管形状(% 任意长,_ 恰一个),Collation 管规矩(CI 不分大小写,CS 分);默认规矩是别人替你定的——用可以,但要知道它在哪、能改、以及你正被它保护着还是坑着。系列小结:五篇下来,查的家底(WHERE/AND/LIKE/ORDER BY/TOP/JOIN/GROUP BY)全部到手。下一站:增、删、改——SQL 里真正动手改数据的三兄弟。