MySQL只读用户能创建临时表？权限设计的精妙之处
许多数据库管理员和开发者都曾有过这样的疑问：为什么已经授予了用户只读权限，他们却依然能在MySQL数据库中创建临时表？这看起来像是一个安全漏洞，但实际上，这正是MySQL权限模型经过深思熟虑后的精妙设计。其核心原因在于，CREATE TEMPORARY TABLE权限与常规的数据写入权限是相互独立的。临时表仅存在于创建它的当前数据库会话中，会话结束后便会自动销毁。它既不持久化存储数据，也不会修改数据库的元数据（metadata）。因此，在MySQL的设计哲学中，创建临时表并不被视为一种“数据写入操作”。只要用户被授予了CREATE TEMPORARY TABLES权限（普通用户默认拥有此权限），即使你只赋予他SELECT和USAGE权限，他依然可以顺利地创建并使用临时表。
如何安全授予只读 + 临时表能力
因此，问题的关键并非在于如何“彻底禁止”所有写操作，而在于如何进行精准、安全的权限组合与管控。务必避免使用GRANT SELECT ON *.*这种过于宽泛且风险极高的授权方式。正确的做法是，按照数据库粒度进行显式授权，并单独补充临时表权限。例如，为一个需要生成复杂报表的用户进行授权：
GRANT SELECT ON `app_db`.* TO 'report_user'@'%'; GRANT CREATE TEMPORARY TABLES ON `app_db`.* TO 'report_user'@'%'; FLUSH PRIVILEGES;
在执行上述授权时，有三个至关重要的细节需要特别注意：
- 权限作用域必须一致：
CREATE TEMPORARY TABLES权限必须和SELECT权限授予到同一个数据库作用域（例如都限定在app_db）。否则，当用户在该库中执行类似CREATE TEMPORARY TABLE t AS SELECT ...的语句时，会直接遇到ERROR 1142 (42000): CREATE TEMPORARY TABLES command denied to user的错误提示。 - 避免全局授权：绝对不要授予
CREATE TEMPORARY TABLES ON *.*这样的全局权限。这可以有效防止用户意外在系统库（如information_schema、mysql）中创建临时表，从而引发不可预知的系统行为或潜在风险。 - 注意连接上下文：如果应用程序在连接数据库后，会固定执行
USE app_db来切换数据库，那么在授权时可以省略库名限定。但权限本身仍需绑定到该特定数据库，否则在进行跨库查询时，创建临时表的语句仍可能因权限作用域不匹配而失败。
临时表能做什么、不能做什么
那么，拥有此权限的用户究竟能用临时表实现哪些功能，又有哪些操作是绝对被禁止的呢？简单来说，临时表是用户进行中间计算、数据暂存和复杂查询的“安全沙盒”，但它无法成为绕过只读限制、影响真实持久化数据的后门。
- ✅ 允许的操作：例如，
CREATE TEMPORARY TABLE tmp AS SELECT id, SUM(val) FROM orders GROUP BY id;，或者利用临时表进行复杂的关联查询：SELECT * FROM tmp JOIN users USING(id);。用户还可以对临时表进行ALTER TABLE tmp ...来修改其结构。 - ❌ 禁止的操作：试图将临时表中的数据写入到持久表中（例如
INSERT INTO real_table SELECT * FROM tmp;）会因为缺乏INSERT权限而失败。同样，删除持久表（DROP TABLE real_table;）或创建新的持久表（CREATE TABLE perm_table (...);）也都是被严格禁止的。 - ⚠️ 需要注意的边界：修改临时表的结构（
ALTER TABLE tmp ...）是允许的，因为这仅影响临时表自身。但一个有趣的细节是，RENAME TABLE tmp TO other_tmp;这条语句会执行失败——因为MySQL目前并不支持对临时表进行重命名操作。
容易被忽略的兼容性细节
随着MySQL版本的不断演进，一些新的默认配置可能会带来意想不到的影响。例如，MySQL 8.0及以上版本默认启用了sql_require_primary_key选项，要求新建的表必须包含主键。但请放心，此选项对临时表无效。不过，这里存在一个陷阱：如果你在创建临时表时显式定义了PRIMARY KEY，而源SELECT语句的结果集中恰好包含重复的主键值，那么CREATE TEMPORARY TABLE ... AS SELECT这条语句会直接报错。因此，更稳妥、兼容性更好的做法是分两步执行：先创建具有空结构的临时表，再插入数据。
CREATE TEMPORARY TABLE tmp (id INT, cnt INT); INSERT INTO tmp SELECT user_id, COUNT(*) FROM logs GROUP BY user_id;
另一个至关重要的细节关乎数据库复制架构：临时表不参与主从复制。它在从库（Slave）上完全不可见。这意味着，如果你的用户是通过中间件（如ProxySQL、MyCat等）连接到一个读写分离的MySQL集群，你必须确保他们的连接会话被正确路由到只读节点。否则，虽然临时表能在主库（Master）连接上创建成功，但后续的SELECT查询一旦被负载均衡器路由到主库或其他只读节点，可能会因为会话隔离而查询不到刚刚创建的临时表数据，从而导致业务逻辑混乱和查询失败。
