查询卡顿但无报错，常见因连接池耗尽、网络延迟、驱动配置不当（如 timeout 设置过长）或 SQL 在客户端快而应用端慢（如未复用连接、预处理缺失）。
为什么 database/sql 查询看起来卡顿，但实际没报错？
常见现象是：SQL 在 MySQL 客户端执行很快（db.QueryRow() 却要 200ms+，且无超时或错误。这通常不是 SQL 本身慢，而是连接建立或复用出了问题。
- 默认
db.SetMaxOpenConns(0)（即不限制），但底层连接池初始为空，首次查询需完整 TCP 握手 + TLS（若启用）+ 认证，耗时集中在这一轮 - MySQL 默认 wait_timeout=8小时，但中间网络设备（如 NAT 网关、云厂商 LB）可能 60–300 秒就静默断连，Go 的
database/sql不主动探测空闲连接是否存活，下次复用时才报错并重连——表现为“偶发性延迟尖刺” - 解决方法：显式配置连接池 + 启用连接健康检查
db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetConnMaxLifetime(3 * time.Hour) // 避免被中间设备踢掉 db.SetConnMaxIdleTime(30 * time.Second) // 主动回收空闲太久的连接
Scan() 太慢？别直接扫 struct，优先用字段索引
用 rows.Scan(&u.ID, &u.Name, &u.Email) 比 rows.Scan(&u)（struct tag 映射）快 15–30%，尤其字段多于 5 个时。反射开销在高频查询中不可忽略。
- struct 扫描需 runtime 获取字段名、匹配列名、类型转换校验；而位置扫描直接按顺序绑定，零反射
- 如果必须用 struct（比如 ORM 场景），确保
db.Query()返回的列顺序与 struct 字段声明顺序严格一致，否则会 silently 赋错值 - 避免
sql.NullString等 wrapper 类型嵌套过深——每层额外接口判断和指针解引用都会叠加微小延迟
批量插入为何比单条还慢？检查 Exec() 是否被自动拆成多语句
写 INSERT INTO users VALUES (?, ?), (?, ?), (?, ?) 本应是一次网络往返，但如果驱动或 MySQL 配置不当，可能被拆成 3 次单条 INSERT 执行。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 确认 MySQL 服务端
max_allowed_packet足够大（至少 16MB），否则大 batch 会被截断降级 - 使用
mysql驱动时，确保连接字符串含multiStatements=true（默认 false），否则带多个 value 组的 INSERT 会被拒绝 - 更稳妥做法：用
db.Prepare()复用 stmt，再循环stmt.Exec()，避免每次解析 SQL —— 即使 batch 写法失效，prepare 仍能省下语法分析时间
事务里读写混合，SELECT FOR UPDATE 卡住？注意隔离级别和索引覆盖
Go 中开启事务后执行 SELECT ... FOR UPDATE，看似只锁几行，结果整张表被堵住，其他普通 SELECT 也变慢。根本原因常是“锁升级”或“间隙锁误伤”。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 默认 REPEATABLE READ，
SELECT FOR UPDATE在无索引条件时会升级为表锁；有索引但非唯一，可能锁住整个索引范围（gap lock） - 务必确认 WHERE 条件命中**唯一索引**或**主键**，否则锁粒度失控
- 避免在事务里做 HTTP 调用、文件读写等长耗时操作——锁持有时间 = DB 操作时间 + 外部延迟，放大阻塞面
连接池参数、字段扫描方式、batch 行为、锁范围——这四点不调，加机器、升配置、换驱动都只是掩盖问题。真正慢的往往不是 SQL，而是 Go 和数据库之间那层“默认假设”。
