连接器是SQL执行的第一道关卡，负责认证、权限校验、线程分配及会话上下文初始化，不参与SQL解析与执行，但决定后续所有步骤能否发生。
连接器是SQL执行的第一道关卡，不是可选环节
MySQL连接器不是“启动后自动就绪”的后台服务，而是每次客户端发起请求时必须显式通过的认证与调度入口。它不参与SQL解析或执行，但决定了后续所有步骤能否发生——没过这一关，SELECT、INSERT甚至SHOW PROCESSLIST都会直接失败。
连接器验证的是会话级权限，不是语句级权限
连接建立时，MySQL从mysql.user表中一次性校验用户名、密码、来源IP，并加载该用户对所有数据库/表的权限快照。这意味着：
- 连接成功后，即使管理员在另一端用
GRANT修改了权限，当前连接仍按旧权限运行，直到断开重连 -
SELECT * FROM orders能执行，不代表UPDATE orders也能执行——后者取决于连接时已加载的权限集合，而非语句本身 - 如果连接使用了
mysql -u appuser -p，而appuser在mysql.user里没有SELECT权限，错误信息是Access denied for user 'appuser'@'%'，不是“Table ‘orders’ doesn’t exist”这类语法或对象错误
连接器分配线程，直接影响并发与超时行为
每个成功连接都会绑定一个服务器线程（或从连接池复用），这个线程生命周期与连接强绑定：
- 空闲连接受
wait_timeout参数控制，默认28800秒（8小时），超时后线程被回收，客户端下次发请求会收到Lost connection to MySQL server during query -
max_connections限制的是同时存在的连接数，不是QPS；当达到上限，新mysql -h ... -u ... -p会卡住或报错Too many connections - 长连接持续占用线程资源，若某查询触发大量临时表或排序缓冲区（如
ORDER BY+LIMIT缺失），内存不会随语句结束释放，而是等到连接断开
连接器不处理SQL文本，但影响后续所有阶段的上下文
连接器本身不碰SQL字符串，但它为后续阶段注入关键上下文：
- 当前默认数据库（由
USE db_name或连接时指定的-D db_name决定），影响未带库名的表引用，如SELECT id FROM users中的users查哪个库 - 会话变量（如
sql_mode、time_zone），这些在连接建立时继承全局值，但可在会话内用SET覆盖，分析器和优化器都依赖它们 - 字符集与排序规则（
character_set_client、collation_connection），决定'中文'这类字面量如何解码，错误配置会导致WHERE name = '张三'查不到数据
真正容易被忽略的是：连接器的工作在mysql>提示符出现那一刻就结束了。之后你敲的每条SQL，都运行在这个已认证、已授权、已分配线程、已设定上下文的会话里——它不重复鉴权，也不重新加载权限，更不会因SQL内容变化而调整自身行为。
