ERROR 1105是MySQL协议兜底错误码，真实原因需结合服务端日志、连接目标（如TiDB/代理）及上下文定位，不能仅凭该码判断SQL错误。
MySQL报错1105的典型触发场景
ERROR 1105 (HY000): Unknown error 是 MySQL 客户端能拿到的最模糊错误之一——它本身不是 MySQL Server 原生错误码，而是由存储引擎、插件或代理层（如 TiDB、ProxySQL、某些中间件）抛出后被 MySQL 协议“兜底”映射成的通用码。真实原因必须结合上下文定位，不能只看这个数字。
排查时优先检查是否用了非官方存储引擎或兼容层
如果你没用 TiDB、PolarDB-X 或自定义 UDF/插件，却遇到 1105，大概率是客户端连接了伪装成 MySQL 的服务（比如某云数据库网关、读写分离代理、或旧版 MySQL Proxy）。这类组件在无法解析语句、权限不足、路由失败时，常统一返回 1105。
- 执行
SELECT VERSION(), @@version_comment;，确认返回值是否含TiDB、AliSQL、Percona等非 Oracle MySQL 标识 - 检查连接串里的 host 是否指向了代理地址（如
proxy.example.com:3306而非真实 DB IP） - 用
mysql --protocol=tcp -h your_host -P your_port -u user -p -e "SELECT 1"绕过本地 socket，排除 client-side 配置干扰
常见具体原因与对应日志线索
真正的问题往往藏在服务端日志里。1105 几乎从不单独出现，一定伴随更具体的提示：
- 如果错误前后有
"Query execution was interrupted"或"Lock wait timeout exceeded"，实际是 1205 或 1213 错误被包装了 - 看到
"unsupported modify type: add column"类提示？那是 TiDB 在拒绝非法 DDL，不是 MySQL 本体问题 - 执行
SHOW WARNINGS;（紧接报错语句后），有时能捞出被截断的底层错误描述 - 开启 general_log 或 slow_query_log，复现操作，看 log 中该语句是否根本没进到 server，而是被前置组件拦截
为什么不能直接靠 1105 判断 SQL 本身有错
一个合法的 INSERT INTO t VALUES (1, 'abc'); 在 TiDB 上可能因表未启用 auto-random 而报 1105；在某云 RDS 上可能因跨 zone 写入被限流返回 1105；甚至客户端 SSL 配置错导致握手后第一个 query 就被代理静默拒绝——现象全是 1105，根因天差地别。
真正要盯的是：你连的是谁？它日志里写了什么？那条 SQL 在它眼里是否合法？
