REPEAT()仅机械重复字符串N次，不支持插值或格式化；需补零应使用LPAD()，跨库兼容建议移至应用层处理。
MySQL 的 REPEAT() 函数怎么用？
直接说结论：REPEAT() 只接受两个参数——字符串和重复次数，不支持占位符、变量插值或格式化。它就是机械地拼接 N 次原字符串，连空格都要你手动加。
常见错误是把它当 printf() 用，比如想生成 "ID: 001" 就写 REPEAT('0', 3) 然后试图拼接，结果发现没法动态替换数字。这不是函数缺陷，是设计定位不同。
-
REPEAT('a', 3)→'aaa'，没问题 -
REPEAT('ID: ', 3)→'ID: ID: ID: '，不是你想要的编号效果 - 传入负数或
NULL次数时，返回NULL，不是空字符串 - 次数为 0 时返回空字符串
''，这点和多数语言一致
想填充固定长度编号（如 001、002），该用什么？
别硬套 REPEAT()，MySQL 有更对口的函数：LPAD()。它才是干“左补零”这类事的标准工具。
场景很典型：把 id 字段转成三位定长字符串，用于日志、单号或排序显示。
-
LPAD(id, 3, '0')→id=5变成'005'，id=123还是'123' - 如果
id是字符串类型（比如来自 JSON 提取），先用CAST(id AS UNSIGNED)转整型，否则LPAD()可能按字符长度截断 - 注意字段实际宽度：若
id可能超过 999，LPAD(id, 3, '0')会原样输出超长值，不会截断 - 性能上
LPAD()和REPEAT()差距可忽略，但语义清晰、不易出错
PostgreSQL 或 SQLite 怎么办？没有 REPEAT() 或 LPAD()？
各数据库函数名和行为不统一，硬记容易踩坑。关键不是背函数，而是分清「重复拼接」和「格式化填充」两类需求。
- PostgreSQL 有
repeat('x', 3)（小写函数名），也有lpad(id::text, 3, '0') - SQLite 没原生
REPEAT()，得用printf('%03d', id)实现补零，但只支持数值；字符串补位要靠substr('000'||val, -3)这类技巧 - 跨库迁移时，
REPEAT()在 MySQL/PostgreSQL 都存在，但参数顺序、NULL 处理略有差异，比如 PostgreSQL 对负数次数抛错，MySQL 返回NULL - 如果项目需兼容多库，建议把这类逻辑提到应用层（如 Python 的
f'{id:03}'），比 SQL 层适配更稳
为什么有人非要用 REPEAT() 拼占位符？常见误区在哪？
本质是混淆了「构造重复结构」和「格式化输出」。比如想生成 10 个短横线做分割线，用 REPEAT('-', 10) 完全合理；但想生成 "[ 5 ]"（数字居中、两边空格对齐），就该用 CONCAT() + SPACE() + 计算逻辑，而不是反复调用 REPEAT() 拼空格。
- 误以为
REPEAT()能替代模板引擎，实际它没解析能力，所有内容都是字面量 - 在 WHERE 或 JOIN 条件里滥用，比如
WHERE name = REPEAT('A', 5)，不如直接写'AAAAA'，还少一次函数调用开销 - 和字符集混用出问题：在 utf8mb4 下，
REPEAT('?', 2)是合法的，但某些旧客户端可能渲染异常，不是函数问题，是传输链路限制
真正难的从来不是函数会不会用，而是第一时间判断：这事儿到底该在 SQL 层做，还是交给程序代码更干净。补零、对齐、模板渲染——越靠近显示逻辑，越该往外推。
