Mysql MyISAM vs InnoDB用于日志记录

我正在优化一个数据库，几乎不知道我的学士学位论文。我决不想让你为我做这项工作，但我有一些问题到目前为止还没有人能回答

表结构：

data_inc，创建表'data_inc'(
“id”bigint（20）非空自动增量，
“id_para”int（10）无符号非空默认值“0”，
“t_s”int（11）无符号非空默认值“0”，
“t_ms”smallint（6）无符号非空默认值“0”，
“t_ns”bigint（20）无符号非空默认值“0”，
“id_inst”smallint（6）非空默认值“1”，
“value”varchar（255）非空默认值“”，
“isanchor”tinyint（4）未签名非空默认值“0”，
主键（'id'，'t_ns'），
键“t_s”（“t_s”），
键“t_ns”（“t_ns”）
)ENGINE=MyISAM自动增量=2128295174默认字符集=1
/*
!50100按范围划分的分区（t\n）
（分区19_02_2015_23_59值小于（142438679900000000）ENGINE=MyISAM，
分区20_02_2015_23_59值小于（1424473199000000000）ENGINE=MyISAM，
分区21_02_2015_23_59值小于（1424559900000000）ENGINE=MyISAM，
分区22_02_2015_23_59值小于（142464599900000000）ENGINE=MyISAM，
分区23_02_2015_23_59值小于（142473239900000000）ENGINE=MyISAM，
分区24_02_2015_23_59值小于（142481879900000000）ENGINE=MyISAM，
分区25_02_2015_23_59值小于（142490519900000000）ENGINE=MyISAM，
分区05_03_2015_23_59值小于（142559639900000000）ENGINE=MyISAM，
分区13_03_2015_23_59值小于（142628759900000000）ENGINE=MyISAM，
分区14_03_2015_23_59值小于（142637399900000000）ENGINE=MyISAM，
分区15_03_2015_23_59值小于（142646039900000000）ENGINE=MyISAM，
分区16_03_2015_23_59值小于（142654679900000000）ENGINE=MyISAM，
分区17_03_2015_23_59值小于（142663319900000000）ENGINE=MyISAM，
分区18_03_2015_23_59值小于（142671959900000000）ENGINE=MyISAM）
*/

该系统目前每秒将多达4000个参数记录到数据库中（不同的表，由存储过程决定）。每隔5分钟、1小时和每天调用不同的脚本来分析日志数据，在此期间，数据被写入表中。这会导致目前的一些重负载。从MyISAM切换到InnoDB（或其他）是否有可能提高性能

---

谢谢你的帮助

用于快速记录，然后进行分析

将数据收集到没有索引的MyISAM表中。5分钟后（1.2M排！）：

将其分析到InnoDB“汇总表”中

删除表或截断表

分析结果将放在其他表格中。这些将具有摘要信息，并且远小于120万行

要获取每小时数据，请汇总汇总表。但不要创建“小时”表；只需根据需要获取并重新计算

---

下面是一些相关的讨论：和。

这一切都取决于数据的结构、需要如何使用它以及有哪些索引类型。我们需要更多信息。

要求我们推荐或查找书籍、工具、软件库、教程或其他非现场资源的问题与堆栈溢出[…]无关。

除此之外，如果您只是插入和读取，但不更新数据，这是记录数据的典型情况，那么你就不需要事务了，你可以使用MyISAM，它在理论上更快，因为它不关心这个特性。没有办法用更多的细节来回答这个问题，但是…一般来说，MyISAM会比innodb更快，因为它是一个“有限”的引擎。没有外键，这消除了大量开销。另一方面，innodb支持行级锁定，而myisam只有表锁。@BenM我添加了更多信息，您还想知道什么？我很乐意提供任何信息，但我真的不知道你必须知道什么才能做出决定。我刚刚在周五遇到你的HowTos，我目前正在尝试将其应用到我的DB中。您知道从暂存表向我的数据库添加分区是否可能（或容易）吗<代码>用t2更改表t1交换分区p或者类似的东西？这是对我的HowTo的一个有趣的“改进”。但我必须仔细考虑一下。一些初步想法：（1）强制在staging表上使用相同的模式；（2） #1所需的任何索引都会减慢插入速度；（3） 这可能（将）导致大量的分区，这有其他性能问题；（4） 等等？？1）确实如此，但是在我的例子中，事实表包含了所有输入的内容（这也不是最优的）。2） 就性能而言，这应该是可能的。可能只有在事实表所需的索引很少（1，可能2）的情况下，这才有效。3） 我计算出一个7天的表有2000多个分区。也许合并表在这里会更好？4） 我在系统中有大量的空闲性能，因为我不再处理一个表（在同一个myisam表上插入和选择），所以节省了很多。2000个分区本身就是一个问题。

分区的性能不太好，比如说，超过50个分区。有些情况下，查询会在实现只需要一个分区之前打开所有分区
MERGE
在十多年来几乎没有得到支持；我不会去那里。如果你也有纳秒，为什么还有秒和毫秒？（这将去掉一个索引）