我需要在生产环境中创建一个MySQL tempory table。该表最多可以包含一列，该列最多可以包含一百万条记录。通常，大约有数千条记录。
我在这里有几个问题
答案 0 :(得分：1)
正如其他人所说，您没有提供很多上下文，因此“取决于情况”。
我非常笼统地说，创建表并在其中存储数据是关系数据库的目的。无论是一行还是数百万，关系数据库爱数据，并且非常擅长优化存储和访问-在这方面，您不可能比MySQL做得更好。
但是...所有服务器都在一定程度上限制了资源。生产服务器通常具有怪异的，不可预测的使用模式。月末对帐运行，一个部门或用户类型的活动突然爆发，报表在星期五下午运行，现实世界似乎并没有按预期的时间表运行。
同样，很笼统地说，数据库服务器往往具有“曲棍球棒”性能曲线-只要您不遇到某些资源瓶颈，响应时间就与使用率有关。然后，当您遇到瓶颈（通常是CPU，RAM或磁盘访问）时，您会发现它在向上弯曲，响应时间急剧增加。
如果在现实世界不可预测的高峰之一期间，生产服务器接近达到该瓶颈点，则添加到该服务器的任何内容（包括临时表）都可能触发拐点。因此，请问了解生产环境的人在高峰时期生产服务器的负载有多大。
下一个需要考虑的问题是，创建和存储数据通常不是性能问题-但是可以查询数据（运行缓慢的查询会占用很多资源，这可能会影响其他进程和用户）。我猜您不只是在存储数据，您还在做一些事情。如果这很慢，或者资源很密集，则可能产生可观的影响。调整并优化查询（在单独的环境上！），确保EXPLAIN显示您正在为所有内容使用索引，并且查询以毫秒为单位返回，并且您大概可以。
有没有更优雅的解决方案？是的，您可以将数据移动到单独的“报告”服务器，在其中可以执行临时表支持的任何处理。
答案 1 :(得分：0)
很抱歉，除了“取决于”之外，没有别的答案，所以答案只能是笼统的。
应用程序在需要时会创建临时表。这是一种正常做法，也是存在临时表的原因之一。 MySQL还在内部为某些操作创建它们。
取决于服务器当前的工作负载及其功能（CPU / RAM / HDD）。
不太可能。最好的选择是让MySQL管理它们。当内存不足（https://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-tablespace.html）
取决于问题的具体情况。将创建表的频率以及将它们保留多长时间。临时表本身可以说是一种优雅的解决方案，因为它可以让您将临时数据保留在一侧，并且避免了多余的数据与处理应用程序之间的复制。