quoted不是mysql内置函数，正确函数是quote()，用于安全包裹字符串并转义特殊字符；标识符需用反引号包裹并配合白名单校验，预处理语句更安全可靠。
MySQL里根本没有QUOTED函数
直接说结论：QUOTED 不是 MySQL 的内置函数，你在官方文档或实际执行中都找不到它。如果你在某段代码或教程里看到 QUOTED('abc')，大概率是混淆了 PostgreSQL 的 quote_literal()、quote_ident()，或是误写了 MySQL 的 QUOTE() 函数。
真正该用的是QUOTE()函数
QUOTE() 是 MySQL 中用于安全包裹字符串的函数，它会自动添加单引号，并转义内部的单引号、反斜杠、ASCII 控制字符等，常用于动态 SQL 构建场景（比如拼接 INSERT 语句）。
常见错误现象：
- 手写 SQL 时直接拼接用户输入，导致
'或\破坏语法（SQL 注入或语法错误） - 误以为
QUOTE()能处理字段名——它只处理字符串字面量，不处理标识符（如表名、列名）
实操建议：
- 对用户输入的字符串值做安全包裹，用
QUOTE('O''Reilly')→ 返回'O\'Reilly' - 不要对数字、NULL 或已知安全的常量调用
QUOTE()，多余且可能引入引号干扰类型推断 - 注意返回值是带引号的字符串，不是原始值；如果后续还要参与字符串拼接，得确认上下文是否需要这层包裹
示例：
SELECT QUOTE('It\'s a test'); -- 返回: 'It\'s a test'
字段名/表名这类标识符怎么安全处理？
MySQL 不提供类似 QUOTE() 的标识符转义函数，但支持用反引号 ` 手动包裹。真正的安全方式是：在生成 SQL 前，用白名单校验或正则过滤标识符内容，再用 ` 包裹。
容易踩的坑：
- 直接把用户输入拼进
SELECT * FROM `user_input`—— 若输入含`或控制字符，仍可能出错 - 误用
QUOTE()处理标识符：QUOTE('order')返回'order'（带单引号），而 MySQL 要求标识符用反引号，单引号会被当字符串字面量解析，直接报错 - 忽略大小写和 SQL 模式影响：在
lower_case_table_names=1环境下，`Order`和`order`可能指向同一张表，但校验逻辑若区分大小写就不可靠
更稳妥的做法：别拼SQL，用预处理
所有涉及用户输入的值，优先走 PREPARE + EXECUTE 预处理语句，让 MySQL 自己处理转义。这是比手动调用 QUOTE() 更可靠的方式。
为什么这样做：
- 绕过字符串拼接的所有转义陷阱，包括编码边界、多字节字符、NUL 字节等
- 性能更好：预处理可复用执行计划，
QUOTE()是运行时函数调用 - 标识符依然不能参数化——表名、列名、ORDER BY 字段必须提前校验后硬编码或用白名单映射
示例（安全传值）：
SET @val = 'O''Reilly';<br>PREPARE stmt FROM 'SELECT * FROM users WHERE name = ?';<br>EXECUTE stmt USING @val;
真正复杂的地方在于：值和标识符的安全处理逻辑完全不同，一个靠函数，一个靠校验+符号包裹，混用就会翻车。很多人卡在“为什么 QUOTE() 结果插进去反而报错”，其实只是把字符串字面量的方案错套到了标识符上。
