我需要在生产环境中创建一个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)
取决于问题的具体情况。将创建表的频率以及将它们保留多长时间。临时表本身可以说是一种优雅的解决方案,因为它可以让您将临时数据保留在一侧,并且避免了多余的数据与处理应用程序之间的复制。