goland 的“read-only connection”仅禁用ide按钮，不阻止真实sql执行；真正生效的是mysql账号权限与read_only配置，需创建专用只读用户并严格授select权限、禁用写权限、刷新权限缓存。
GoLand 里配数据库只读模式根本没用
GoLand 的 Database 工具窗口里勾选 “Read-only connection” 或在数据源设置里开 “Read-only” 选项，只是告诉 IDE 别让你点“Execute Statement”按钮，不拦真实 SQL 执行。你写个 DELETE FROM users 然后按 Ctrl+Enter，只要连接本身有权限，照样删——IDE 不是 MySQL 权限网关。
真正起作用的是 MySQL 账号权限和 read_only 配置
GoLand 连接数据库用的账号，才是决定能不能删数据的关键。如果你连的是 root@localhost，哪怕 GoLand 界面标着“只读”，执行 DROP TABLE 依然成功。
- 开发环境必须创建专用只读账号：
CREATE USER 'dev_ro'@'localhost' IDENTIFIED BY 'pwd'; - 只授 SELECT 权限：
GRANT SELECT ON `myapp_db`.* TO 'dev_ro'@'localhost'; - 回收所有写权限：
REVOKE INSERT, UPDATE, DELETE, DROP, CREATE, ALTER, INDEX, LOCK TABLES ON *.* FROM 'dev_ro'@'localhost'; - 验证结果：
SHOW GRANTS FOR 'dev_ro'@'localhost';输出里不能出现任何 DML/DDL 权限词
别碰 read_only = ON —— 它对 GoLand 连接无意义，且 root 用户默认绕过，反而让你误以为“已锁死”。
GoLand 连接配置要匹配账号权限
在 Data Sources 设置里填的用户名，必须是你刚建的 dev_ro，不是 root。否则前面白忙。
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- Host 填
localhost（不是127.0.0.1），因为 MySQL 认为这是两个不同 host，权限不复用 - Database 填具体库名（如
myapp_db），避免账号意外获得information_schema或其他库的访问权 - Connection pool 里关掉 “Auto-commit”，但注意：这只是影响事务提交方式，不改变权限
连上后右键表名选 “Open Table” 是安全的；但一旦你手动敲 INSERT 并执行，就会收到 ERROR 1142 (42000): INSERT command denied —— 这才是真正的只读生效信号。
容易被忽略的坑：临时表、系统表、多库授权
只读账号如果没限制库范围，可能无意查到敏感信息；而某些操作看似只读，实则隐式写入：
-
CREATE TEMPORARY TABLE不受read_only限制，但受账号权限约束——所以只授SELECT就能天然封住它 - 别用
GRANT SELECT ON *.*，否则mysql.user、performance_schema全暴露；逐个库授权：GRANT SELECT ON `myapp_db`.*、GRANT SELECT ON `log_db`.* - 如果业务真需要跨库查，检查每个库是否都该被开发看到；不该看的，干脆不授，比事后审计强
最常漏的一环是忘记 FLUSH PRIVILEGES;，尤其在旧版 MySQL 上——改完权限不刷缓存，新账号还是按旧权限跑。
