mysqli_query()不支持多语句执行，因MySQLi默认禁用该功能以防范SQL注入；必须使用mysqli_multi_query()，但需手动处理结果集、上下文隔离及错误检查，且仍存在注入风险。
mysqli_query() 不能执行多条 SQL 语句，强行拼接分号会导致只执行第一条或直接报错；必须用 mysqli_multi_query()，但仍有上下文隔离、错误处理和注入风险等硬性限制。
为什么 mysqli_query() 不支持多语句
MySQLi 默认禁用多语句执行，这是底层客户端库的安全策略——防止攻击者在单个输入点注入多条恶意命令（比如 DROP TABLE users; --）。即使你把 CREATE DATABASE 和 USE db_name; 写在同一字符串里，mysqli_query() 也只会解析并执行第一个语句，后续内容被忽略或触发 You have an error in your SQL syntax 错误。
常见错误现象：
- SQL 字符串含多个分号，但只创建了数据库，没建表
- 执行后无报错但表不存在，查
mysqli_error()发现是“Unknown database” - 用
mysqli_query($conn, "CREATE DATABASE test; USE test;")，第二条USE完全不生效
用 mysqli_multi_query() 的三个前提条件
它能执行多语句，但每条语句仍独立运行，且不会自动继承前一条的上下文（比如数据库选择）。必须手动推进结果集并检查每条语句的状态。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
mysqli_next_result()主动跳转到下一条语句的结果，否则后续mysqli_store_result()会失败 -
USE database_name这类语句没有返回结果集，但会影响后续语句的执行环境；如果中间有错误，后续语句仍会继续执行（不中断） - 所有语句共用同一个连接上下文，但无法跨语句共享变量或临时表，也不能依赖前一条语句的
LAST_INSERT_ID()等状态
示例片段：
if (mysqli_multi_query($conn, "CREATE DATABASE IF NOT EXISTS myapp; USE myapp; CREATE TABLE users(id INT)")) {
do {
if ($result = mysqli_store_result($conn)) {
mysqli_free_result($result);
}
} while (mysqli_next_result($conn));
}
更安全的替代方案：分步 + 预处理
绝大多数初始化场景（如部署脚本、安装向导）根本不需要多语句。分步执行反而更可控、易调试、防错能力强。
- 先用
mysqli_query($conn, "CREATE DATABASE ...")创建库 - 立刻调用
mysqli_select_db($conn, 'myapp')显式切换上下文，比USE更可靠 - 再用
mysqli_query()执行建表语句 —— 此时上下文已明确，不会出现 “no database selected” - 对后续所有用户输入参与的查询，一律改用
PDO::prepare()或mysqli_prepare()，避免注入
注意：mysqli_select_db() 返回布尔值，必须检查是否成功；失败时后续建表必然报错。
动态语句组合时的注入风险
哪怕用了 mysqli_multi_query()，只要语句中拼接了未过滤的用户输入（比如数据库名、表名），就仍可能被注入。预处理语句不支持占位符用于数据库名或表名，所以必须白名单校验。
- 禁止直接拼接：
"CREATE DATABASE " . $_POST['db_name'] - 必须白名单验证：
in_array($_POST['db_name'], ['app_v1', 'app_v2'], true) - 或正则过滤：
preg_match('/^[a-zA-Z0-9_]{2,32}$/', $_POST['db_name']) - 敏感操作（如
DROP、TRUNCATE）应完全禁用，或加二次确认机制
真正容易被忽略的点是：多语句执行本身不解决上下文污染问题，也不提供自动参数化能力——它只是“放行”，不是“兜底”。安全边界仍在开发者手上。
