MySQL 57.24在Windows VM上运行。它有几千个数据库(7000个)。我知道这不是MySQL的推荐设置,但一些业务需求需要这种多租户数据库结构,不幸的是,我不能改变这一点。
服务器在运行时工作正常,但启动时间可能会很长,在MySQL服务完全关闭后几乎20-30分钟,在Windows VM重新启动后1个多小时。
有没有办法缩短启动时间?
在我的配置中,我观察到innodb_file_per_table = ON(这是MySQL 5的默认值。7我相信),所以我认为,在启动时,它是扫描每.ibd文件。
将innodb_file_per_table = OFF更改为OFF,然后更改每个表以摆脱。IBD文件是可行的选择。需要注意的一点是,一般来说,每个数据库的大小都很小,即使有7000个数据库,数据的总大小也只有60 GB左右。因此,根据我的理解,innodb_file_per_table = ON在单个表可能变得非常大时更有用,而我的服务器不是这样。
**问题:**我的逻辑是否合理,这个innodb_file_per_table会不会是启动慢的原因?或者有一些其他的配置变量,我可以改变,使每个。在服务器开始接受连接之前不扫描ibd文件。
任何帮助,引导我在正确的方向将不胜感激。先谢谢你了!
2条答案
按热度按时间ds97pgxw1#
你应该升级到MySQL 8。0.
我在研究一个和你有同样问题的系统。在我们的例子中,每个MySQL示例有大约1500个模式,每个模式有100多个表。因此,每个示例大约有160,000多个表。尝试使用
innodb_file_per_table
会导致很多问题,因为mysqld进程无法有效地处理那么多打开的文件描述符。使系统正常工作的唯一方法是放弃每个表一个文件的做法,并将所有表移到中央表空间中。但这会引起另一个问题。表空间永远不会缩小,只会增大。缩小表空间的唯一方法是将表移动到另一个表空间,并删除大表空间。
有一天,一个开发人员添加了一些代码,使用了一个像日志一样的表,非常快速地插入了大量的行。我让他停止记录那些数据,但那时已经太晚了。MySQL的中央表空间已经扩展到数据库存储大小的95%,留给binlog和其他文件的空间太少了。我不可能在不给我们的生意带来停工期的情况下缩小它。
我问他:“你为什么对着那张table写那么多东西?”你在用你存储的数据做什么?他耸耸肩,漫不经心地说:“我不知道,我想这些数据可能会有意思,但我对它们没有特别的用途。“我想掐死他。
这个故事的重点是,如果禁用
innodb_file_per_table
,一个天真的开发人员可能会带来很多不便。MySQL 8.0正在计划中,MySQL产品经理征求可伸缩性标准的想法。我告诉他需要支持有很多表的示例,比如160 k或更多。MySQL 8.0包含了一个全新的内部代码实现,用于处理关于表的元数据,他要求工程师测试多达100万个表的可扩展性(启用了每个表的文件)。
因此,解决问题的最佳方法是不要关闭
innodb_file_per_table
。这只会导致另一种危机。最好的解决方案是升级到8。0.回复您的评论:
据我所知,InnoDB不会在启动时打开表。它在第一次查询表时打开表。
确保您已针对您的秤调整了
table_open_cache
和innodb_open_files
。以下是一些阅读:我希望您使用的是SSD存储,而不是旋转磁盘。这在执行大量小型I/O操作时会产生巨大的差异。SSD存储设备一直是数据库服务器的标准建议约有10年。
此外,这可能对你没有帮助,但我在2007年左右放弃了使用Windows。不是服务器,也不是桌面。
7cjasjjr2#
MySQL不能有效地支持巨大的数据库