最直接的方式是查 mysql.user 表的 Create_tmp_table_priv 字段：SELECT Host, User, Create_tmp_table_priv FROM mysql.user WHERE User = 'your_user' AND Host = 'your_host';若值为 Y 则有权限，N 或空值则无权。
直接查 mysql.user 表的 Create_tmp_table_priv 字段
MySQL 的临时表权限是独立控制的，不随 CREATE 权限自动赋予。最直接的方式是查系统表：
SELECT Host, User, Create_tmp_table_priv FROM mysql.user WHERE User = 'your_user' AND Host = 'your_host';注意必须同时匹配
User 和 Host，因为权限是按组合生效的。如果返回结果中 Create_tmp_table_priv 是 Y，说明有权限；N 或空值都代表无权。
用 SHOW GRANTS 看当前生效的显式授权
SHOW GRANTS 只显示通过 GRANT 显式授予的权限，不反映 mysql.user 表里可能被手动改过的字段值（比如直连 root 改表绕过授权机制）：
SHOW GRANTS FOR 'your_user'@'your_host';如果输出里包含
CREATE TEMPORARY TABLES，那该用户确实被授过这个权限。但要注意：即使这里没出现，也不能断定没权限——有可能是全局权限被禁用、或账号被 REVOKE 后未刷新权限缓存。
实际执行 CREATE TEMPORARY TABLE 测试最可靠
权限检查最终要落到行为上。用目标用户连接后尝试建一个最小临时表：
CREATE TEMPORARY TABLE test_tmp (id INT);成功则说明权限有效；失败时看错误信息：
-
ERROR 1142 (42000): CREATE command denied to user ... for table 'test_tmp'→ 确实缺权限 -
ERROR 1044 (42000): Access denied for user ... to database 'test'→ 可能是数据库级权限不足（比如只给了USAGE），而非临时表权限本身问题
DROP TEMPORARY TABLE test_tmp;，虽然会话断开自动销毁，但主动清理更稳妥。
注意 FLUSH PRIVILEGES 不影响临时表权限的实时性
修改 mysql.user 表后必须执行 FLUSH PRIVILEGES; 才能让变更生效，这点和普通 GRANT 不同。GRANT 语句会自动重载权限，但直改系统表不会。另外，MySQL 8.0+ 的角色（role）机制下，如果用户通过角色获得该权限，还需确认角色已激活：SET ROLE ALL;，否则 SHOW GRANTS 可能不显示，但实际权限仍存在。
