只靠参数化查询不够，因运维脚本、DBA客户端等可绕过应用层防护，数据库账号权限才是最后一道防线；需按服务精准授予列级SELECT/INSERT/UPDATE权限，显式回收DROP、CREATE等高危权限，并覆盖定时任务、环境账号、第三方SDK等盲区。
为什么只靠参数化查询还不够？
大型电商系统里，SELECT、INSERT、UPDATE 甚至 DELETE 操作分散在几十个微服务中，哪怕每个接口都用了 PreparedStatement 或 ORM 参数绑定，一旦某个运维脚本、后台导出任务、或 DBA 临时排查用的 SQL 客户端连上了生产库，就可能绕过所有应用层防护。这时候，数据库账户本身的权限边界就成了最后一道防线。
如何给应用账号分配「刚好够用」的权限？
电商系统常见模块对应最小权限应这样配：
- 商品搜索服务：仅需
SELECT权限，且限制在products、categories、skus三张表；禁止对users、orders表有任何访问 - 订单创建服务：允许
INSERT到orders和order_items，但UPDATE仅限status字段（用列级权限），禁止DELETE - 库存扣减服务：必须有
UPDATE权限到inventory表，但仅限quantity和updated_at字段；禁止SELECT整表（防批量查库存） - 后台报表服务：使用只读从库账号，且通过视图封装，比如
vw_daily_sales_summary，不暴露原始交易明细表
MySQL / PostgreSQL 中实际执行的权限语句
别直接用 GRANT ALL PRIVILEGES —— 这是高危操作。真实环境中要逐条收紧：
GRANT SELECT(id, name, price) ON products TO 'search_app'@'%'; GRANT INSERT, UPDATE(status, updated_at) ON orders TO 'order_app'@'%'; GRANT UPDATE(quantity, updated_at) ON inventory TO 'stock_app'@'%';
注意：UPDATE 列级权限在 MySQL 8.0+ 和 PostgreSQL 中原生支持，但旧版本需靠视图或存储过程兜底；REVOKE DROP, CREATE, ALTER, FILE, PROCESS 等高危权限必须显式执行，不能依赖“默认不给”。
容易被忽略的三个盲区
权限最小化不是一劳永逸的事：
- 定时任务使用的数据库账号常被遗忘——比如每天凌晨跑销量统计的 Python 脚本，可能还连着一个拥有
SELECT所有表的旧账号 - 开发/测试环境数据库账号权限照搬生产库，导致本地调试时误删测试数据，或掩盖了权限不足的 bug
- 第三方 SDK（如某些老版支付回调通知组件）会悄悄执行
SHOW TABLES或SELECT @@version，若被拒绝可能引发异常中断，需提前白名单放行元数据查询
真正卡住攻击链的，往往不是最炫的防护技术，而是那个没人记得改、也没人敢动的数据库账号配置。
