MySQL存储过程分页必须用CONCAT拼接SQL+PREPARE/EXECUTE，因不支持动态LIMIT参数；PHP调用需禁用PDO模拟预处理，并用FOUND_ROWS()获取总数。
PHP 调用 MySQL 存储过程实现分页，**不能靠存储过程直接返回 LIMIT 偏移量参数**——因为 MySQL 存储过程不支持动态 LIMIT，PREPARE + EXECUTE 是唯一可行路径，且必须由存储过程内部拼接 SQL 并执行。
MySQL 存储过程里怎么写带分页的动态查询
存储过程无法把 LIMIT ?, ? 当作普通参数传入静态 SQL，必须用预处理语句。常见错误是直接写 SELECT * FROM t LIMIT offset, size 并把 offset 和 size 声明为 IN 参数——这会报错 ERROR 1064。
- 必须用
CONCAT()拼出完整 SQL 字符串，例如：SET @sql = CONCAT('SELECT * FROM users WHERE status = ', p_status, ' ORDER BY id DESC LIMIT ', p_offset, ', ', p_size); - 紧接着调用
PREPARE stmt FROM @sql;和EXECUTE stmt; - 记得最后
DEALLOCATE PREPARE stmt;，否则连接内存泄漏 - WHERE 条件中的用户输入（如字符串）必须手动加引号并转义，或改用
QUOTE()函数，避免 SQL 注入
PHP 怎么安全调用这个分页存储过程
PHP 的 mysqli 或 PDO 都不能直接 bind_param 给 LIMIT，所以 PHP 层只需传入整型偏移和数量，并信任存储过程内部已做类型校验和转义。
- 用
PDO::prepare("CALL page_users(?, ?, ?)")传参，其中前两个是过滤后的intval($_GET['page'])和intval($_GET['size'])，第三个是状态等业务条件 - 务必设置
PDO::ATTR_EMULATE_PREPARES = false，否则 PDO 会模拟预处理，导致存储过程内PREPARE失败 - 调用后用
$pdo->query("SELECT FOUND_ROWS() AS total")->fetch()['total']获取总记录数（前提是存储过程里执行了SELECT COUNT(*)或用了SQL_CALC_FOUND_ROWS） - 不要在 PHP 中拼接 SQL 再交给存储过程——失去封装意义，也增加注入风险
为什么不用纯 PHP 分页而要用存储过程
只有当分页逻辑极其复杂（多表 JOIN + 条件嵌套 + 聚合计算 + 权限过滤）且被多个语言/系统共用时，才值得上存储过程。否则徒增维护成本。
立即学习“PHP免费学习笔记（深入）”；
- 调试困难：MySQL 日志不记录预处理语句实际执行内容，
SHOW PROCESSLIST看不到拼出的 SQL - 缓存失效：每次
EXECUTE都算新查询，无法利用 MySQL 查询缓存（8.0 已移除，但应用层缓存也难命中） - 迁移成本高：换 PostgreSQL 或 SQL Server 就得重写全部存储过程
- 简单分页（如单表 + 无复杂条件）用 PHP 计算
offset后直连SELECT ... LIMIT ?, ?更快更稳
真正麻烦的不是调用那几行 PHP 代码，而是存储过程里字符串拼接的引号、空格、类型转换和权限隔离——少一个 TRIM() 或漏判 NULL，查出来就是空结果或全表扫。
