In my previous post about InnoDB Stalls on Empty Free List, I used a test environment that might look a little artificial : a table larger than the InnoDB Buffer Pool but fitting in the Linux Page Cache. This configuration allows serving very quickly what MySQL thinks are IOs because these are hit in the filesystem cache. In this post, I explain why this environment is not totally artificial
In one of my previous posts, I shared InnoDB table compression statistics for a read-only dataset using the default value of innodb_compression_level (6). In it, I claimed, without giving much detail, that using the maximum value for the compression level (9) would not make a big difference. In this post, I will share more details about this claim.
TL;DR: tuning innodb_compression_level is not
TL;DR: we still need MyISAM and myisampack because it uses less space on disk (half of compressed InnoDB) !
In the previous post, I shared my experience with InnoDB table compression on a read-only dataset. In it, I claimed, without giving much detail, that using MyISAM and myisampack would result is a more compact storage on disk. In this post, I will share more details about this claim.
In my last post about big MySQL deployments, I am quickly mentioning that InnoDB compression is allowing dividing disk usage by about 4.3 on a 200+ TiB dataset. In this post, I will give more information about this specific use case of InnoDB table compression and I will share some statistics and learnings on this system and subject. Note that I am not covering InnoDB page compression which is