資料庫延遲

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資料庫的主從延時的兩種方法就介紹到這里了，希望本次的介紹能夠對您有所收獲！