公司打印室的打印机总是卡在“正在连接”状态，等得人火大。其实问题可能不在设备本身，而藏在后台的数据库里。每次点击打印，系统都要查一遍用户权限、文档记录、设备状态，如果数据表没有合理建立索引，查询就像在图书馆找一本没编号的书——慢得离谱。
为什么打印任务会卡在队列里？
很多单位用统一平台管理打印扫描操作，所有请求都写入数据库。比如一张A4纸的打印记录，可能要插入到 print_log 表中，同时更新 user_quota 和 device_status。随着数据量增长，这些表的查询速度下降，尤其当字段如 user_id 或 printer_name 没有索引时，系统就得全表扫描。
想象一下，公司有两千员工，每天五百次打印任务，三年下来 print_log 表可能已有几十万行。这时候再按用户名查历史记录，没索引的话响应时间可能从毫秒级变成几秒。
哪些字段该加索引？
重点看那些常出现在 WHERE、JOIN 和 ORDER BY 后面的字段。比如：
SELECT * FROM print_log WHERE user_id = 1024 AND printer_name = 'Office_Laser_3' ORDER BY submit_time DESC;这种查询频率高，就应该在 (user_id, printer_name, submit_time) 上建复合索引。注意顺序：等值查询字段在前，范围或排序字段在后。
别乱建索引，否则更慢
索引不是越多越好。每加一个索引，插入新打印记录时就要多更新一次索引树。打印机日志这种写多读少的场景，过度索引反而拖慢整体性能。比如给 print_content 字段加索引，既占空间又几乎不用，纯属浪费。
定期检查无用索引也很重要。可以用数据库自带的工具查看索引使用频率，长时间没被命中的就考虑删掉。
实际优化案例
某部门反馈扫描归档系统越来越卡。排查发现 scan_records 表在 file_path 字段上建了索引，但查询其实主要靠 scan_date 和 uploader。去掉 file_path 索引，加上 (uploader, scan_date) 的组合索引后，页面加载从 4.8 秒降到 0.3 秒。
有时候一条 ALTER TABLE 就能让打印队列流畅起来，比换硬件便宜多了。