在系统对接外部服务商时，最稳妥的做法不是把主库账号交给对方，而是单独建一个MySQL用户，并且只允许它访问某一个SCHEMA。这样即便第三方程序有漏洞，也不会波及订单、用户等核心库。下面先说明具体落地方式。
一、为什么需要用SCHEMA隔离第三方账户
很多团队图省事，给第三方直接用了拥有全库权限的账号，结果对方一条不带条件的DELETE就把日志表清空了。MySQL里的SCHEMA相当于独立命名空间，把不同业务的数据放进去之后，账号的权限可以精确到某个SCHEMA。只给第三方开通某一个SCHEMA，就等于在逻辑上砌了一道墙。
从运维角度看，这种隔离也方便审计。你只要看那个SCHEMA的慢查询和连接数，就能判断第三方程序是否异常。如果将来合作终止，直接DROP USER或者REVOKE就行，不用改其他系统的配置。
二、创建独立的第三方账户
先用root或管理员账号登录MySQL，创建一个只能从指定IP连进来的用户。限制来源IP能避免账号被拿到别处爆破。下面的例子创建了用户api_third，密码是复杂字符串，只允许从192.168.0.1访问。
CREATE USER 'api_third'@'192.168.0.1' IDENTIFIED BY 'StrongPass#2024!Word';
如果第三方需要从任意IP接入，可以把主机部分写成'%'，但生产环境不建议。创建完用SELECT user,host FROM mysql.user;能确认账号已经存在。此时该账号没有任何权限，连SHOW DATABASES都只能看到自己被授权的库。
注意密码策略。若MySQL开启了validate_password组件，密码太简单会报错。可以用随机串加大小写字母和数字，避免弱口令。账号建好后再授权，不要提前给ALL PRIVILEGES。
三、利用SCHEMA限定访问范围
假设我们已经有一个叫third_data的SCHEMA专门给外部用，里面放了对账明细表。现在把该SCHEMA下所有表的SELECT和INSERT权交给api_third，其他SCHEMA它根本看不到。
GRANT SELECT, INSERT ON third_data.* TO 'api_third'@'192.168.0.1'; FLUSH PRIVILEGES;
第三方用这个账号登录后，运行SHOW DATABASES;只会列出third_data。即便它执行USE mysql;也会报拒绝访问。这样就实现了用SCHEMA画边界。如果还要允许更新，可以追加GRANT UPDATE，但一般只读加写入明细就够了。
权限粒度也能下钻到表级。例如只开放third_data.bill表，就写GRANT SELECT ON third_data.bill。对列级控制MySQL也支持，但第三方场景通常到表就够了。每次改完权限记得FLUSH PRIVILEGES，让授权表重新加载。
四、日常维护与回收
合作方需要换密码时，用ALTER USER改掉即可，不影响程序结构。下面语句把密码重置，旧连接断开后新连接必须用新密码。
ALTER USER 'api_third'@'192.168.0.1' IDENTIFIED BY 'NewComplexPass@99';
若发现对方越权尝试，或者合作结束，用REVOKE收权或直接删账号。REVOKE只收部分权限，DROP USER连账号一起清除。示例如下：
REVOKE INSERT ON third_data.* FROM 'api_third'@'192.168.0.1'; DROP USER 'api_third'@'192.168.0.1';
建议定期用SHOW GRANTS FOR 'api_third'@'192.168.0.1';复查授权，确认没有多余权限。配合审计日志，基本能堵住第三方接入带来的主要隐患。
五、常见误区
有人以为把第三方放在独立SCHEMA就绝对安全，其实如果那个SCHEMA里存了敏感字段且程序有SQL注入，依然会泄露。SCHEMA隔离是边界控制，不是加密替代。另外，不要给第三方SUPER或FILE权限，否则它能读服务器文件或杀掉其他线程。
还有人用root给不同第三方建库却共用一个账号，这等于没隔离。每个外部方都应对应独立用户加独立SCHEMA，这样出事能精准切断。理清这两点，MySQL对外接入的账户体系才算合格。