initcap是postgresql等少数数据库原生支持的函数，将每个单词首字母大写、其余小写，按空格和标点切分；mysql/sql server等不支持，需应用层处理或复杂函数组合模拟。
INITCAP 在标准 SQL 中并不存在
绝大多数数据库（如 MySQL、SQL Server、SQLite）压根不提供 INITCAP 函数。你执行 SELECT INITCAP('hello world'); 很可能直接报错：Unknown function 'INITCAP' 或类似提示。PostgreSQL 是少数原生支持它的主流数据库，但行为也有细节陷阱。
PostgreSQL 中 INITCAP 的实际表现
PostgreSQL 的 INITCAP 确实能将每个单词首字母转大写、其余转小写，但它按空白符和标点切分“单词”，且对非 ASCII 字符处理保守：
-
INITCAP('JOHN DOE')→'John Doe' -
INITCAP('e-mail_address')→'E-Mail_Address'（下划线和连字符也被当分隔符） -
INITCAP('café')→'Café'（带重音字符通常保留，但依赖当前 locale 设置） - 它不处理缩写（如
'U.S.A.'仍变成'U.S.A.'，不会变'U.s.a.'）
其他数据库的等效替代方案
MySQL、SQL Server 等需组合函数手动实现，核心思路是：拆分 → 首字母大写 + 其余小写 → 拼接。但没有通用单行解法，必须根据场景选：
- MySQL 8.0+ 可用
REGEXP_REPLACE+UPPER/LOWER模拟，但正则不支持捕获组回溯，只能处理简单空格分隔； - SQL Server 推荐用
STRING_SPLIT（2016+）配合FOR XML或STRING_AGG（2017+）拼接，再对每段用UPPER(LEFT(...,1)) + LOWER(SUBSTRING(...,2,LEN(...)))； - SQLite 完全没字符串分割函数，基本只能靠应用层处理，或借助扩展（如
json1模块做 hack 式解析）； - 如果只是固定格式（如姓名字段），用两层
REPLACE处理常见缩写（REPLACE(REPLACE(LOWER(name), ' ', ' _'), '_', ' ')这类技巧误差大，慎用）。
真正需要首字母大写的场景，优先考虑应用层
数据库层模拟 INITCAP 成本高、可读性差、难以覆盖所有边界（如撇号、连字符、多语言）。除非数据量极大且必须在查询时统一格式（如报表视图），否则更可靠的做法是：
- 在应用代码中用语言原生方法处理（Python 的
string.capwords()、JavaScript 的split(' ').map(w => w.charAt(0).toUpperCase() + w.slice(1).toLowerCase()).join(' ')）； - 若必须数据库内处理，先确认是否真要改变原始数据——多数时候只是展示需求，用前端或中间层格式化更灵活；
- PostgreSQL 用户注意：
INITCAP会强制小写其余字母，如果源数据含正确缩写（如'iPhone'），它会变成'Iphone'，这点常被忽略。
