MySQL客户端允许省略分号，因其仅作为客户端判断语句结束的提示符，服务端实际接收时已剥离分号；单条完整SQL（如SELECT 1）可直接执行，但多语句、SQL文件或特定驱动场景仍需分号。
MySQL 客户端（mysql CLI）为什么允许省略分号
MySQL 命令行客户端 mysql 本身不是 SQL 引擎，而是一个交互式前端程序。它对输入的处理分两层：先由客户端解析语句边界，再把完整语句发给服务端执行。分号只是客户端用来判断“用户是否输完了”的默认语句结束符，不是 MySQL 服务端语法必需的。
- 客户端检测到换行且当前输入未闭合（比如引号、括号没配对），会自动续行，不提交
- 输入以分号结尾，客户端立即切分并发送给服务端
- 输入以
\g或\G结尾，效果等同于分号（\G还会格式化输出） - 如果一行里只写了
SELECT 1没加分号，客户端会直接执行——因为它能明确判断这是完整语句
SELECT 1 SELECT * FROM user WHERE id = 1
这两条在 mysql CLI 中都能直接运行，因为客户端能基于关键字和语法结构做简单断句。
MySQL 服务端其实根本不认分号
MySQL 服务端（mysqld）接收的是已切分好的语句字符串，分号早在客户端就已被剥离。你用其他方式调用（如 Python 的 mysql-connector、Java 的 JDBC），传入的 cursor.execute("SELECT 1") 里带不带分号都无所谓，驱动通常会自动忽略或报错（取决于配置）。
- 存储过程、函数、触发器内部的 SQL 语句必须用分号，是因为要和
BEGIN...END块里的语句分隔 - 但那里的分号是被存储程序解析器处理的，不是服务端 SQL 解析器认的
- 直接执行的单条语句，服务端连见都见不到分号
哪些情况不写分号会出问题
- 在 mysql CLI 中输入多条语句时，不写分号会导致全部粘成一句，报错
ERROR 1064 (42000) - 使用
source或.执行 SQL 文件时，文件里必须用分号分隔语句，否则只有第一句生效 - 某些客户端（如 DBeaver、Navicat）默认关闭“自动分号”，但若开启多语句执行（
allowMultiQueries=true），仍需显式分号 - 写在 shell 脚本里用
mysql -e "SELECT 1; SELECT 2"，这里的分号是 shell 字符串的一部分，不是 MySQL 的，但恰好被 mysql CLI 识别为语句结束
Python / Node.js 等应用代码里要不要加分号
不用，也不该加。
-
mysql-connector-python遇到语句末尾的分号会警告Warning: (1785, "Statement is not safe to log in statement format.")（尤其在 GTID 模式下） -
pymysql和mysql2（Node.js）会原样传给服务端，但服务端忽略它；不过混在参数化查询中可能干扰占位符解析 - 更关键的是：分号可能被误当作注入点，比如用户输入
admin'; DROP TABLE user; --，如果代码拼接时又额外加了分号，风险放大
cursor.execute("SELECT * FROM user WHERE name = %s;", ("admin'; DROP TABLE user; -- ",))这种写法看似加了分号，实则让恶意输入更易突破语义边界。
分号看起来只是个标点，但它横跨客户端解析、服务端执行、驱动行为、安全边界四层逻辑——漏掉它不一定报错，加上它却可能悄悄改变语义或暴露漏洞。
