mysql 一次插入多少条是最佳性能
-
我们经常会浏览，分享，点赞，都会产生数据，这些数可能会被存储到不同的地方，其中最常见的存储载体就是--数据库。
- 根据场景和数据特性，可以有关系型数据库mysql，也有非关系数据库，例如：Redis，比如说：当你在网站点赞的时候，为了快速响应，可能是一个基于内存的数据库如Redis首先记录这个动作，后台在周期性能的同步这些动作到持久化的存储系统中。
问题：当巨大数据流入时，如何高效稳定的把数据存储到数据库中，每次多少条，
- 很多时候，我们只知道批量插入可以提高性能，我们要知道为什么？
问题：如何快速插入，并保证有效性，
答案：
1.写入缓存与磁盘同步。
2.事务日志与数据持久化
1.写入缓存与磁盘同步：
当数据被写入数据库时，它首先应该被写入缓存中，而不是缓慢的磁盘中，然后后台线程在适当的时间点将数据同步到磁盘上。
这样做的原因：
1.速度差异：RAM（随机取存储器）的速度远远快于磁盘，RAM读数据的读取几乎是瞬间，而磁盘，无论传统的机械硬盘，还是现代的固态硬盘，读写速度都低于RAM。
2。磁盘I/O的成本：每次进行磁盘的I/O操作都有一定的开销，如果数据库频繁的进行小批量的磁盘写入，会导致I/O开销，得不偿失。
首先将数据写入RAM，在数据库可以把数据同步到磁盘之前，累积多个写入操作，最后一次大量的数据写入磁盘，从而减少I/O的次数和开销。
结论：先写入缓存，在同步到磁盘，这种不仅仅加速了写入操作，有效的减少了I/O，提高数据库性能
问题：如果数据库还不及到磁盘，结果宕机了。
InnoDB在进行更新操作时候，采用了，writeAhead Log 策略，这就是意味着：数据被写入磁盘之前，相关的操作会首先记录到redo log日志里面，这种策略赋予了mysql在系统崩溃后的恢复能力。
2.事务日志与数据持久化：
为了确保数据的完整性，数据库首先将插入操作写入事务，只有当数据安全的写入日志，才会移动到实际的数据库表中。
单条插入和批量数据插入的差异：
单条插入1000次，就是1000次的事务开销，批量插入，可以将这些数据在一个事务中插入，大大减少了总的事务开销。
批量插入对数据库性能的影响：
批量插入可以减少磁盘I/O的次数，从而提高性能，但是如果一次批量数据量过大，它可能会暂时阻塞其他的操作，影响数据的响应时间。
为了达到最佳的性能可能需要根据实际的情况调整插入的数据量，过少的数据导致数据库性能优化不足，过多的数据导致响应时间增加。
如何决定合适的数据插入量
1.磁盘I/O：
磁盘I/O是插入数据的瓶颈之一：过多的插入操作，会导致磁盘I/O的饱和，降低系统的响应时间。
确保在高插入时候：不能超过其峰值。
2.大量插入时候可能会增加RAM的使用量，定期检查内存，确保有足够的资源来处理大量的插入操作。
3.事务的大小：
较大的事务：可能导致长时间的锁定，从而影响其他查询的性能。
太小的事务：增加事务的数量，性能优化没有太大意义。
估值的计算：
- 比如一条记录：字段Int,4字节varchar,最小50字节最大255字节，date,3字节，float 4字节。
这条记录的大小：4+50+3+4=61字节；
最大记录大小：4+255+3+4=266字节；
2. 内存分析：
假如：8G内存，预留20%，可使用是：80.8=6.4G
so:我们可以插入的最大记录是：
最大记录数（平均大小）：6.410的9次方字节 / 61字节
最大记录数（最大大小）：6.4*10的9次方字节 / 266字节
- 硬盘分析：
假如是：512G硬盘，可以存储的最大记录数为：
最大记录数（平均大小）：51210的9次方字节 / 61字节
最大记录数（最大大小）：51210的9次方字节 / 266字节
避免频繁的会话提交
在批量插入期间，频繁的会话可能会导致，性能下降，一般在插入完所有的数据后再进行一次会话提交。
