数据库延迟

1. 数据条数太多，插入到数据库有延迟，怎么解决

1.我们往数据库中导入的数据通常是有固定的模板的，也就是有列头，但是可能excel中的一条数据分布存储在不同的数据表中，那么我们怎么判物来导入了，我们可以在类文件中直接拼接sql语句插入，这样做的话我认为比较麻烦。我的做法是：在数据中建一个中间表暂且叫做Temp表跟excel中列一一对应，其中表中多加state列用来标识数据验证失败还是成功的（0代表数据没有问题，-1代表有问题）、failReason记录导入失败原因，然后再添加一个配置文件来做excel列和数据表的映射。 2.要导入的数据通常要做验证，那些不符合导入规则的数据时不允许或者不能导入的。我把数据分两步来验证，一部分在代码段验证，一部分在数据库验证。至于怎么分那就自己去根据情况分析了。我是把诸如字符长度限制，正则表达式规则限制等放 在代码段验证，把诸如数据库中字典值是否存在等要访问数据库的验证放在数据中验证，这样的话就可以减少访问数据库的次数。把再客户端验证过的数据，不管是通过的不同过的都插入到temp表中，只是state值不同。 3.然后怎么把插入temp中数据分别插入到不同的数据表中了，大家一定想到了触发器，没有错，我用的就是after触发器，在我把excel中的数据插入到temp表中的时候，那么就会触发after触发器，在触发器中对插入的数据进行处理，如果插入的数据state值为-1，代表在代码端的验证就没有通过，那么就不需要进行下一步处理了，如果state值为0，那么在触发器中接着处理，比如检测字典值在字典表中存不存在等，如果不满足要求就把temp表中的当前插入的记录state值改成-1，把校验失败原悔厅因更新到failReason字段中，不再处理。如果一切校验都没有问题的话，那么就编写插入语句，把数据插入到不同的表中去。 4.数据导入完成了，掘前液那么那些有问题数据怎么办了？把它查询出来生成一个按原模板后加一列“失败原因”导成excel文件，其实就是state值为-1的那些记录，然后返回给用户查看。 通过以上步骤之后那么整个导入功能就完成了，以上只是一种思路，望大家完善。 本站技术原创栏目文章均为中睿原创或编译，

2. 如何解决主从数据库同步延迟问题

最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也橘袜可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。
sync_binlog=1
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction
默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢 失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘 同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，MySQL服务器 处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍 然存在binlog中。可以用--innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释：在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的圆族激确切数据等，并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。
innodb_flush_log_at_trx_commit （这个很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的穗册数据。而值2只会在整个操作系统 挂了时才可能丢数据。

3. 怎样解决MySQL数据库主从复制延迟的问题

在主服务器上建立一个为从服务器进行复制使用的用户。该账户必须授予 REPLICATION SLAVE 权限，由于仅仅是进行复制使用所以不需要再授予任何其它权限。

mysql> GRANT REPLICATION SLAVE ON *.* TO 'replication'@'%'192.168.0.2' IDENTIFIED BY 'slavepasswd';
mysql> FLUSH PRIVILEGES;

3、编辑主服务器的配置文件：/etc/my.cnf的[ mysqld ] 部分：
server-id = 本机数据库 ID 标示，该部分还应有一个server-id=Master_id选项，其中master_id必须为1到232之间的一个正整数值
log-bin = 二进制日志的位置和名称
binlog-do-db = 需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可
binlog-ignore-db = 不需要备份的数据库苦命，如果备份多个数据库，重复设置这个选项即可

4. 测量从数据库延迟的方法有

主从延时排查方法：
第一种方法：
1.showmasterstatusG;#查看主库的position号记录到多少了。
2.从库中执行showslavestatusG;#查看从库现在获取到哪个position号了.
3.如果从库的postion号远小于主库的position号,则表示主库mp线程传送二进制出问题了.
第二种方法(推荐)：
通过监控showslavestatus命令输出的“Seconds_Behind_Master”参数的值来判断NULL，表示io_thread或是sql_thread有任何一个发生故障；
0，该值为零，表示主从复制良好；正值，表示主从已经出现延时，数字越大表示从库延迟越严重。为了再现这种高并发时刻，测试指令为：ab-c12-n10000http://tp5pro.com/index/test。

5. 微信小程序云开发关于数据库读取延迟问题的解决

目前有很多专业的小程序开发公司，主要分为以下两类

第一种：卖模板的小程序公司

优点是：价格低，5000-10000元，适合对小程序功能没太多要求，急裂辩需上线的企业

缺点是：这种模板“一键生成”的小程序，需要按年续费，并非永久拥有自己的小程序；这种模板小程蚂友序也无法开发个性化功能，后肆物缺期无法实现二次开发。

第二种：定制开发的小程序开发公司

优点是：独一无二的，专为你的企业或者店面定制的，功能你来定，要求你来定，后期修改BUG方便，二次开发添加功能也很方便，最重要的是永久使用权！

缺点是：价格较高，一般一万到十几万不等，具体看功能需求了

最后总结，具体选择模板小程序还是定制开发小程序，要看公司的具体需求和预算了

6. 如何检查MySQL数据库的主从延时

MySQL数据库主从延时如何去判断呢？本文我们介绍了两种判断方法：1. Seconds_Behind_Master vs 2. mk-heartbeat，接下来我们就分别介绍这些内容。 日常工作中，对于MySQL主从复制检查，一方面我们要保证复制的整体结构是否正常，另一方面需要检查主从数据是否保持一致。对于前者我们可以通过监控复制线程是否工作正常以及主从延时是否在容忍范围内，对于后者则可以通过分别校验主从表中数据的md5码是否一致，来保证数据一致，可以使用Maatkit工具包中的mk-table- checksum工具去检查。 方法1： 通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。其值有这么几种： NULL — 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No，而非Yes。 0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。 正值— 表示主从已经出现延时，数字越大表示从库落后主库越多。 负值— 几乎很少见，我只是听一运缓些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。 show slave status\G，该命令的输出结果非常丰厚，给我们的监控提供了很多有意义的参数，比如旁烂模：Slave_IO_Running该参数可作为 io_thread的监控项，Yes表示io_thread的和主库连接正常并能实施复制工作，No则说明与主库通讯异常，多数情况是由主从间网络引起的问题；Slave_SQL_Running该参数代表sql_thread是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。下面就说到今天的重点Seconds_Behind_Master，该值作为判断主从延时的指标，那么它又是怎么得到这个历卜值的呢，同时，它为什么又受到很多人的质疑？ Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和 io_thread复制好的event的timestamp（简写为ts）进行比较，而得到的这么一个差值。我们都知道的relay-log和主库的 bin-log里面的内容完全一样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的一致。 你也会发现，其实比较真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了，当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而 sql_thread一直都能跟上io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与 master网络很好的情况下，那么该值也是很有价值的。 之前，提到Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。 方法2： mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。 mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳 now()，该结构也会被复制到从库上。 表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示延时的秒数越多。 我们都知道复制是异步的ts不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制，巧妙的借用timestamp来检查延时，非常好用！ 关于检查MySQL数据库的主从延时的两种方法就介绍到这里了，希望本次的介绍能够对您有所收获！