LIMIT不能防止SQL注入，真正有效的是参数化查询；需用bindValue绑定整型LIMIT参数并设硬上限，表名等动态部分须白名单校验。
用 LIMIT 防 SQL 注入？别被误导了
LIMIT 不能防止 SQL 注入，它只限制结果行数，对恶意拼接的语句毫无防御力。攻击者照样能执行 UNION SELECT、INSERT 或 UPDATE，甚至用 SELECT ... INTO OUTFILE 写文件——这些操作根本不受 LIMIT 约束。
真正起作用的是参数化查询。所有用户输入必须走绑定参数，不拼字符串，不信任任何外部数据源。
PHP PDO 中正确限制查询行数 + 防注入
在确保使用预处理的前提下，再加 LIMIT 才有意义：既控量，又避免全表扫描拖垮数据库。
- 用
bindValue()绑定LIMIT参数，且必须指定类型为PDO::PARAM_INT - 不要直接把用户传的
$_GET['limit']转成整数后拼进 SQL —— 这等于开了后门 -
LIMIT值建议设硬上限（比如最多 100 行），超出则截断或报错
SELECT id, name FROM users WHERE status = ? LIMIT ?
执行时：$stmt->bindValue(1, $status, PDO::PARAM_STR); $stmt->bindValue(2, min((int)$limit, 100), PDO::PARAM_INT);
MySQL 的 max_rows 和 SQL_BUFFER_RESULT 不是安全机制
这两个配置项常被误认为“防注入手段”，其实完全无关：
-
max_rows是表级提示，仅影响优化器估算，不强制截断结果 -
SQL_BUFFER_RESULT只是把结果暂存在临时表里，方便释放锁，和安全性零关系 - 它们都不校验 SQL 结构，也不阻止多语句执行（如
; DROP TABLE users）
依赖这类配置来“防注入”，相当于给门装了个装饰性插销。
PostgreSQL 和 SQLite 的等效做法
不同数据库语法略有差异，但核心原则不变：参数化优先，LIMIT 是辅助控制。
- PostgreSQL 同样支持绑定
LIMIT参数，但注意它不接受负数，0表示返回空集 - SQLite 的
LIMIT必须是常量或问号占位符，不能是表达式（如LIMIT ? + 1会报错near "+": syntax error） - 如果业务需要分页，优先用游标（cursor-based pagination），而不是
OFFSET+LIMIT，后者在大数据集下性能崩得快，还容易漏/重数据
最易被忽略的一点：即使用了参数化，如果错误地把表名、字段名、排序方向（ASC/DESC）也当作变量拼进去，照样中招。这些没法参数化，必须白名单校验。
