我正在运行 Snort 与 MySQL 进行日志记录，这会产生巨大的数据集（目前事件表超过 250 万，我不知道具体是多少，因为它最多只能达到 250 万，之后就会因为使用了太多内存而变得很笨重）。
不幸的是，这些数据不再有用，因为我无法从其他任何地方将其提取出来（存储过程导致服务器崩溃）。
我的问题是，有没有办法针对这些庞大的数据集优化 MySQL，或者这超出了 MySQL 的技术能力，我需要使用 Oracle、MS SQL 或 PostgreSQL 之类的东西？
我们同时拥有 Oracle 和 MS SQL Server 实例，但这两者都是业务关键型生产服务器，如果其中一个服务器离线或抑制其功能，那将是非常糟糕的消息。
对此事有什么想法吗？
答案1
就像其他人所说的那样 - 2.5M 并不是很大的行数。看看你的模式设计 - 你的报告是否会运行可以使用索引的全表扫描[警告：引入新索引会降低插入性能]。
您是否尝试过优化 innodb？确保至少索引适合缓冲池内存。尝试mysqltuner.pl或者如果你有更多时间 - 深入研究mysqlperformanceblog.com。
答案2
250 万条记录应该没问题。共享架构会有所帮助。此外，mysqltuner.pl（在另一个答案中提到）会警告您一些 my.cnf 问题 - 例如 innodb_buffer_pool 小于索引的大小。一定要运行它。innodb_buffer_pool 应尽可能设置得高。
如果您有任何文本列，那么如果您将这些列移到单独的表中，则任何涉及扫描大量行的查询都会表现得更好。更好的方法是使用 InnoDB 插件、Percona Server 或 MariaDB，并对这些新的文本列表启用压缩。
答案3
也许innodb不是日志的最佳选择？
我有一个集中式系统日志服务器，它的设置是每个月将数据发送到不同的/新的表，并且有一个视图将所有这些表连接起来。然后使用 myisampack 压缩旧日志，这样它们占用的空间就少了很多，读取速度更快，并且变为只读。它运行非常快。