只读账号不能替代参数化查询，因其无法修复SQL注入的代码层漏洞，攻击者仍可通过SELECT类注入（如UNION、报错、盲注）窃取全部敏感数据，仅能阻止DELETE/UPDATE/DROP等写操作。
只读账号无法阻止SQL注入发生，但能显著限制攻击后果——它拦不住数据被“查”，但能挡住数据被“删”“改”“增”或“执行命令”。
为什么只读账号不能替代参数化查询
SQL注入是代码层漏洞，根源在未使用prepare()或PreparedStatement拼接SQL。只读账号不修复这个缺陷，攻击者仍可执行SELECT类注入（如联合查询、报错注入、盲注），完整拖走用户表、密码哈希、甚至数据库结构信息。它只是让DROP TABLE、UPDATE users SET password='xxx'、INSERT INTO logs这类语句直接报错拒绝。
- 错误认知：以为“设成只读就安全了” → 实际上敏感数据早已裸奔
- 真实价值点：把“全库沦陷”降级为“仅数据泄露”，避免业务直接瘫痪
- 典型失败场景：后台用只读账号连库，但管理员功能另配了高权限连接池，且该连接池被注入利用
只读账号对不同注入类型的实际拦截效果
不是所有注入都会被阻断，效果取决于攻击者目标和数据库行为：
-
UNION SELECT注入：✅ 通常成功（只读账号允许SELECT）→ 可窃取其他表数据 - 报错注入（如
EXTRACTVALUE(1, CONCAT(0x7e, (SELECT DATABASE())))）：✅ 成功（表达式求值不依赖写权限） - 布尔/时间盲注：✅ 成功（仅靠
SELECT条件真假或延时判断） -
INSERT/UPDATE/DELETE注入：❌ 直接报错ERROR 1142 (42000): INSERT command denied to user - 堆叠注入（
;分隔多语句）：❌ 大部分MySQL客户端默认禁用多语句，即使开启，后续DROP等操作也会因权限不足失败 - 写文件类攻击（
SELECT ... INTO OUTFILE）：❌ 权限不足，除非显式授予FILE权限（绝不该授）
配置只读账号时容易忽略的三个坑
只读 ≠ 绝对安全，配置不当会留下缝隙：
- 误授
SHOW DATABASES或INFORMATION_SCHEMA读权限 → 攻击者可自动枚举所有库名、表名、字段名，极大加速注入过程 - 忘记回收
GRANT OPTION→ 账号可能自行提权或转授他人 - 应用中混用账号：登录态用只读账号，但“导出报表”“同步缓存”等功能悄悄切到高权限账号，且该路径存在注入点 → 防御形同虚设
最危险的错觉，是以为权限控制能弥补代码缺陷。真正兜底的只有参数化查询；只读账号只是最后一道闸门——它不防偷，只防砸。
