2. 程式人生 > >讓天下沒有難用的資料庫 » 為什麼我的RDS慢了？

讓天下沒有難用的資料庫 » 為什麼我的RDS慢了？

阿新 • • 發佈：2018-12-29

為什麼我的RDS突然變慢了？相信這是大多數客戶在使用RDS中經常遇到的頭疼問題。下面我將通過實際的真實案例來分析一下使用者在使用RDS中慢的原因：

案例一：使用者從PGSQL遷移到RDS後，發現RDS變慢了.

問題描述：使用者的資料庫（pgsql）遷移到RDS（mysql）後，發現相同的一條sql語句，資料量百萬級左右，在原來postgreSQL中執行大概是0.015s，而在RDS下直接執行是6分20秒左右，執行非常的慢，已經嚴重的影響了使用者使用RDS使用的信心.

可能原因：為什麼在使用者的資料庫上執行只需要0.015s，而到RDS後變為了6分20s？根據經驗，很有可能是SQL的執行計劃改變了，而導致執行時間劇增.

問題排查：通過explain檢視sql的執行計劃，一步一步進行優化.

mysql> EXPLAIN SELECT a.oid,
    ->        a.tid,
    ->        a.created,
    ->        a.pay_time,
    ->        a.consign_time,
    ->        a.endtime,
    ->        c.nick,
    ->        c.user_name,
    -
 
>        e.shop_name,
    ->        d.num_iid,
    ->        d.title,
    ->        f.status_name,
    ->        a.payment,
    ->        a.num,
    ->        a.refund_status,
    ->        a.refund_fee,
    ->        d.outer_id
    ->   FROM
 
 xxxx_test a
    ->   LEFT JOIN xxxx_test1 c ON a.customerno = c.user_id
    ->   LEFT JOIN xxxx_test2 d ON a.num_iid = d.num_iid
    ->   LEFT JOIN xxxx_test3 e ON a.dp_id = e.shop_id
    ->   LEFT JOIN xxxx_test4 f ON a.ccms_order_status = f.status_id
    ->  WHERE EXISTS
    ->  (SELECT 1 FROM xxxx_test5 b WHERE a.tid = b.tid);
+----+--------------------+--------------------+--------+---------------+---------+---------+---------------------------+---------+-------------+
| id | select_type        | TABLE              | TYPE   | possible_keys | KEY     | key_len | REF                       | ROWS    | Extra       |
+----+--------------------+--------------------+--------+---------------+---------+---------+---------------------------+---------+-------------+
|  1 | PRIMARY            | a                  | ALL    | NULL          | NULL    | NULL    | NULL                      | 1055789 | USING WHERE |
|  1 | PRIMARY            | retail_tb_customer | eq_ref | PRIMARY       | PRIMARY | 152     | xxxx_db.a.customerno        |       1 |             |
|  1 | PRIMARY            | d                  | eq_ref | PRIMARY       | PRIMARY | 152     | xxxx_db.a.num_iid           |       1 |             |
|  1 | PRIMARY            | e                  | eq_ref | PRIMARY       | PRIMARY | 152     | xxxx_db.a.dp_id             |       1 |             |
|  1 | PRIMARY            | f                  | eq_ref | PRIMARY       | PRIMARY | 2       | xxxx_db.a.ccms_order_status |       1 |             |
|  2 | DEPENDENT SUBQUERY | b                  | ALL    | NULL          | NULL    | NULL    | NULL                      |     452 | USING WHERE |
+----+--------------------+--------------------+--------+---------------+---------+---------+---------------------------+---------+-------------+

通過分析，我們可以從執行計劃上分析b表做了一個全表掃描(執行計劃的最後一行)，檢視b表中tid並無索引，所以我們這裡可以進行優化，來減少查詢過程中關聯的行數，來達到優化：

ALTER TABLE xxxx_test5 ADD INDEX ind_twf_node_order_analysis_tid(tid);
mysql> EXPLAIN SELECT a.oid,
    ->        a.tid,
    ->        a.created,
    ->        a.pay_time,
    ->        a.consign_time,
    ->        a.endtime,
    ->        c.nick,
    ->        c.user_name,
    ->        e.shop_name,
    ->        d.num_iid,
    ->        d.title,
    ->        f.status_name,
    ->        a.payment,
    ->        a.num,
    ->        a.refund_status,
    ->        a.refund_fee,
    ->        d.outer_id
    ->   FROM xxxx_test a
    ->   LEFT JOIN xxxx_test1 c ON a.customerno = c.user_id
    ->   LEFT JOIN xxxx_test2 d ON a.num_iid = d.num_iid
    ->   LEFT JOIN xxxx_test3 e ON a.dp_id = e.shop_id
    ->   LEFT JOIN xxxx_test4 f ON a.ccms_order_status = f.status_id
    ->  WHERE EXISTS
    ->  (SELECT 1 FROM xxxx_test5 b WHERE a.tid = b.tid);
+----+--------------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+---------+--------------------------+
| id | select_type        | TABLE              | TYPE   | possible_keys                   | KEY                             | key_len | REF                       | ROWS    | Extra                    |
+----+--------------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+---------+--------------------------+
|  1 | PRIMARY            | a                  | ALL    | NULL                            | NULL                            | NULL    | NULL                      | 1055789 | USING WHERE              |
|  1 | PRIMARY            | retail_tb_customer | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.customerno        |       1 |                          |
|  1 | PRIMARY            | d                  | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.num_iid           |       1 |                          |
|  1 | PRIMARY            | e                  | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.dp_id             |       1 |                          |
|  1 | PRIMARY            | f                  | eq_ref | PRIMARY                         | PRIMARY                         | 2       | xxxx_db.a.ccms_order_status |       1 |                          |
|  2 | DEPENDENT SUBQUERY | b                  | REF    | ind_twf_node_order_analysis_tid | ind_twf_node_order_analysis_tid | 153     | xxxx_db.a.tid               |       2 | USING WHERE; USING INDEX |
+----+--------------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+---------+--------------------------+

我們可以看到執行計劃中的rows已經從452變為了2(執行計劃的最後一行)，由於mysql的表關聯只有nest loop join這種演算法，所以我們可以估算一下這裡的優化：

原始執行一：1055789*1*1*1*1*452 掃描的行數

新執行計劃二：1055789*1*1*1*1*2 掃描的行數

執行時間：

mysql> SELECT a.oid,
    ->        a.tid,
    ->        a.created,
    ->        a.pay_time,
    ->        a.consign_time,
    ->        a.endtime,
    ->        c.nick,
    ->        c.user_name,
    ->        e.shop_name,
    ->        d.num_iid,
    ->        d.title,
    ->        f.status_name,
    ->        a.payment,
    ->        a.num,
    ->        a.refund_status,
    ->        a.refund_fee,
    ->        d.outer_id
    ->   FROM xxxx_test a
    ->   LEFT JOIN xxxx_test1 c ON a.customerno = c.user_id
    ->   LEFT JOIN xxxx_test2 d ON a.num_iid = d.num_iid
    ->   LEFT JOIN xxxx_test3 e ON a.dp_id = e.shop_id
    ->   LEFT JOIN xxxx_test4 f ON a.ccms_order_status = f.status_id
    ->  WHERE EXISTS
    ->  (SELECT 1 FROM xxxx_test5 b WHERE a.tid = b.tid);
....................
..........省去結果
8 ROWS IN SET (10.62 sec)

我們看到執行時間已經由原來的6分20秒下降到了10秒，我們繼續優化； 我們可以看到該sql的結果集只有區區的8行，但是掃描的行數卻是非常之大的（1055789*1*1*1*1*2），在優化sql的非常關鍵的一點就是優化sql 的執行路程，t=s/v；如果我們能夠優化S，那麼速度肯定會一下子提上來； 那麼我們在看看sql中最後的一句：

-> WHERE EXISTS
-> (SELECT 1 FROM xxxx_test5 b WHERE a.tid = b.tid);

sql查詢中是要查詢出每筆訂單的詳細資訊而不得不關聯其他一些表，但是最後的一個exist限定了我們最後結果的範圍，在看看xxxx_test5 這張表有多大：

mysql> SELECT COUNT(*) FROM xxxx_test5;
+----------+
| COUNT(*) |
+----------+
| 403 |
+----------+
1 ROW IN SET (0.00 sec)
mysql> SELECT COUNT(*) FROM xxxx_test5 b ,xxxx_test a WHERE a.tid = b.tid
-> ;
+----------+
| COUNT(*) |
+----------+
| 8 |
+----------+
1 ROW IN SET (0.42 sec)

兩張表關聯後只有8行記錄，如果我們將訂單表xxxx_test和限定表先做關聯，在和其他的一些訂單資訊表做連線，將會極大的減小關聯的行數；在進一步改寫sql：

mysql> EXPLAIN SELECT a.oid,
    ->        a.tid,
    ->        a.created,
    ->        a.pay_time,
    ->        a.consign_time,
    ->        a.endtime,
    ->        c.nick,
    ->        c.user_name,
    ->        e.shop_name,
    ->        d.num_iid,
    ->        d.title,
    ->        f.status_name,
    ->        a.payment,
    ->        a.num,
    ->        a.refund_status,
    ->        a.refund_fee,
    ->        d.outer_id
    ->   FROM xxxx_test5 g,xxxx_test a
    ->   LEFT JOIN xxxx_test1 c ON a.customerno = c.user_id
    ->   LEFT JOIN xxxx_test2 d ON a.num_iid = d.num_iid
    ->   LEFT JOIN xxxx_test3 e ON a.dp_id = e.shop_id
    ->   LEFT JOIN xxxx_test4 f ON a.ccms_order_status = f.status_id
    ->   WHERE g.tid=a.tid;
+----+-------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+------+-------------+
| id | select_type | TABLE              | TYPE   | possible_keys                   | KEY                             | key_len | REF                       | ROWS | Extra       |
+----+-------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+------+-------------+
|  1 | SIMPLE      | g                  | INDEX  | ind_twf_node_order_analysis_tid | ind_twf_node_order_analysis_tid | 153     | NULL                      |  452 | USING INDEX |
|  1 | SIMPLE      | a                  | REF    | idx_xxxx_test_tid               | idx_xxxx_test_tid               | 153     | xxxx_db.g.tid               |    1 | USING WHERE |
|  1 | SIMPLE      | retail_tb_customer | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.customerno        |    1 |             |
|  1 | SIMPLE      | d                  | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.num_iid           |    1 |             |
|  1 | SIMPLE      | e                  | eq_ref | PRIMARY                         | PRIMARY                         | 152     | xxxx_db.a.dp_id             |    1 |             |
|  1 | SIMPLE      | f                  | eq_ref | PRIMARY                         | PRIMARY                         | 2       | xxxx_db.a.ccms_order_status |    1 |             |
+----+-------------+--------------------+--------+---------------------------------+---------------------------------+---------+---------------------------+------+-------------+
6 ROWS IN SET (0.00 sec)

分析執行計劃，我們發現限定表xxxx_test5做了驅動表，驅動表的變化才是導致問題的最根本原因，掃描的行數：452*1*1*1*1； 這個時候sql的執行速度就飛一般的感覺了：

mysql> SELECT a.oid,
    ->        a.tid,
    ->        a.created,
    ->        a.pay_time,
    ->        a.consign_time,
    ->        a.endtime,
    ->        c.nick,
    ->        c.user_name,
    ->        e.shop_name,
    ->        d.num_iid,
    ->        d.title,
    ->        f.status_name,
    ->        a.payment,
    ->        a.num,
    ->        a.refund_status,
    ->        a.refund_fee,
    ->        d.outer_id
    ->   FROM xxxx_test5 g,xxxx_test a
    ->   LEFT JOIN xxxx_test1 c ON a.customerno = c.user_id
    ->   LEFT JOIN xxxx_test2 d ON a.num_iid = d.num_iid
    ->   LEFT JOIN xxxx_test3 e ON a.dp_id = e.shop_id
    ->   LEFT JOIN xxxx_test4 f ON a.ccms_order_status = f.status_id
    ->   WHERE g.tid=a.tid;
..................
........省去結果
8 ROWS IN SET (0.13 sec)

總結：由於環境的遷移，導致sql執行計劃的改變，這就是RDS變慢的最終原因了。

案例二：使用者使用RDS(mssql),經常出現連線超時報錯

問題描述：使用mssql rds時不時報錯如下A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)，詢問是否是連線超過限制導致的？

可能原因：可能使用者的應用程式設計不是很好導致資料庫鎖爭用較多；或由於沒有建立適當的索引導致全表掃描導致，造成了資料庫等待；

問題排查：通過檢視資料庫的監控指標，發現在某個時間段有大量的全表掃描，同時資料庫的鎖爭超時，會話數明顯增加.

可以看到在15：00的時候有大量的全表掃描，出現了較多的鎖超時的情況，同時這個時候也有大量的會話在資料庫中，而這個時間恰好也是使用者報出錯誤的時間，在進一步排查，使用者的SQL，通過檢視mssql內部的一些檢視，來找到對應消耗資源top 5的sql，發現使用者使用頻繁的查詢一個檢視，在檢視中有多表連線，但在這些表連線中的欄位上沒有新增索引，導致了全表掃描，使用者檢視如下：

CREATE VIEW [dbo].[Vi_xxx]
AS
SELECT ..........
..........
FROM dbo.xxxx_test6 INNER JOIN
dbo.xxxx_test1 ON dbo.xxxx_test5.docID = dbo.xxxx_test1.docID INNER JOIN
dbo.xxxx_test2 ON dbo.xxxx_test5.typeID = dbo.xxxx_test2.typeID INNER JOIN
dbo.xxxx_test3 ON dbo.xxxx_test5.docID = dbo.xxxx_test3.docID INNER JOIN
dbo.xxxx_test4 ON dbo.xxxx_test5.categoryID = dbo.xxxx_test4.categoryID
WHERE (dbo.xxxx_test5.isDelete = 0)

通過檢視執行計劃，發現表上面很多的關聯欄位沒有建立索引，導致全表掃描 執行計劃如下(有很多的table scan)：總結：使用者頻繁的查詢一個檢視，而該檢視中表的關聯欄位上沒有索引，導致了大量的全表掃描，累積了大量的會話數，造成資料庫效能的下降，應用與資料庫之間出現連線錯誤。

案例三：隱式轉換導致全表掃描

問題描述：使用者網站開啟緩慢，質疑RDS效能不好.

可能原因：使用者的資料存放在RDS中，網站訪問資料庫的時間較長，絕大部分都是使用者自己的應用程式設計不好，SQL寫的不優化，索引建立的不好而導致；

問題排查：通過檢視資料庫的慢日誌，發現大量的慢sql，執行時間超過了2S.

UPDATE USER SET xx=xx+N.N WHERE account=130000870343  LIMIT 10
SELECT * FROM  USER WHERE account=13056870  LIMIT 10

懷疑在user表上是否建立索引：
CREATE TABLE `user` (
`id` smallint(5) unsigned NOT NULL AUTO_INCREMENT,
`account` char(11) NOT NULL COMMENT ‘???’,
…………………….
…………………….
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`account`),
…………………….
) ENGINE=InnoDB CHARSET=utf8 ;
檢視執行計劃，居然查詢使用了全表掃描： [email protected] 16:55:06>explain select * from user where account=13056870343;
+—-+————-+——–+——+—————+——+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+—-+————-+——–+——+—————+——+———+——+——+————-+
| 1 | SIMPLE | t_user | ALL | username | NULL | NULL | NULL | 799 | Using where |
+—-+————-+——–+——+—————+——+———+——+——+————-+
1 row in set (0.00 sec)

為什麼這裡會是全表掃描喃？account上不是已經建立索引來嗎？仔細一看，account定義為了字串，而傳入的條件為數字，我們知道數字的精度是比字串高的，所以這裡做了隱士轉換：to_number(account)=13056870343（to_number為將字串轉換為數字），這樣即使account上有索引，也沒法使用了，因此我們將傳入的數字改為字串：

[email protected] 16:55:13>explain SELECT * FROM USER WHERE account='13056870343';
+----+-------------+--------+-------+---------------+----------+---------+-------+------+-------+
| id | select_type | TABLE  | TYPE  | possible_keys | KEY      | key_len | REF   | ROWS | Extra |
+----+-------------+--------+-------+---------------+----------+---------+-------+------+-------+
|  1 | SIMPLE      | t_user |

相關推薦

讓天下沒有難用的資料庫 » 為什麼我的RDS慢了？

為什麼我的RDS突然變慢了？相信這是大多數客戶在使用RDS中經常遇到的頭疼問題。下面我將通過實際的真實案例來分析一下使用者在使用RDS中慢的原因： 案例一：使用者從PGSQL遷移到RDS後，發現RDS變慢了. 問題描述：使用者的資料庫（pgsql）遷移到RDS（mysql）後，發現相同的一條sql語

讓天下沒有難用的資料庫 » RDS MySQL空間優化最佳實踐

在前三期介紹了RDS for MySQL引數優化，鎖問題以及延遲優化最佳實踐之後，本期將介紹儲存空間相關的最佳實踐。 儲存空間是RDS很重要的一個指標，在RDS的工單問題中，空間問題的諮詢可以排在top 5，當RDS的實際使用空間超過了購買的空間後，例項就會被鎖定了，這樣就會導致應用無法再寫入，更新

讓天下沒有難用的資料庫 » 我是如何加入阿里的

一年一度的校園實習招聘馬上開始了，最近接觸了幾個找工作的應屆生同學，回想當年自己找工作的時候，也是遇到了很多好心人，所以心中一直想寫一篇回憶以前經歷的文章，算是對自己有一個交代，也希望能夠幫助到這些找工作的同學，好吧，接下來就是憑自己回憶的流水賬了。 一.一顆種子的種下 我的母校是四川師範大學，專業

讓天下沒有難用的資料庫 » RDS彈性升級後效能反而下降的案例

剛剛結束的2015年雙11，天貓以912億的成交量再次打破去年的記錄成為一個奇蹟，大家可能不知道，這些天貓的訂單最後的處理都是放在阿里雲聚石塔的機房完成，從2012年開始，淘寶的ISV，商家就開始把他們的訂單，CRM後臺系統逐漸遷移到雲上，最核心的資料庫就是存放在RDS中。 雙11之前使用者都會進行

讓天下沒有難用的資料庫 » RDS MySQL引數調優最佳實踐

前言 很多時候，RDS使用者經常會問如何調優RDS MySQL的引數，為了回答這個問題，寫一篇blog來進行解釋： 哪一些引數不能修改，那一些引數可以修改； 這些提供修改的引數是不是已經是最佳設定，如何才能利用好這些引數； 哪些引數可以改 細心的使用者在購買RDS的時候都會看到，不同規格能夠提供

讓天下沒有難用的資料庫 » 如何將RDS的資料同步到本地自建資料庫

長期以來有很多的使用者諮詢如何將RDS的資料同步到本地的資料庫環境中，本篇文章以在阿里雲的ECS伺服器為例來說明如何將RDS的資料同步到本地資料庫中。RDS對外提供服務是一個DNS地址+埠3306，這樣就遮蔽了RDS後端的主從節點，那麼該如何將資料同步到本地？那麼我們來看一下RDS的主從架構： 應

讓天下沒有難用的資料庫 » 關於RDS只讀例項延遲分析

只讀例項是目前RDS使用者實現資料讀寫分離的一種常見架構，使用者只需要將業務中的讀請求分擔到只讀節點上，就可以緩解主庫查詢壓力，同時也可以把一些OLAP的分析查詢放到另外的只讀節點上，減小複雜統計查詢對主庫的衝擊，RDS只讀節點架構圖如下： 由於RDS只讀節點採用原生的MySQL Binlog複製

讓天下沒有難用的資料庫 » RDS鏈路卡慢問題的診斷

經常會收到使用者反饋在使用RDS的過程中出現卡慢，閃斷地情況，當出現此類問題的時候，首先我們要進行一下測試，看看問題出現在哪一個階段，RDS給到使用者的是一個DNS地址，其實他包括三個階段：DNS–>VIP–>DB        我們可以在本地的應用伺服器（VM）上通過簡單的ping命

讓天下沒有難用的資料庫 » 關於RDS例項CPU超過100%的分析

經常聽見使用者說自己的rds例項cpu超過100%，通常這種情況都是由於sql效能問題導致的,下面我用一則案例來分析： 使用者例項zuowenwang反映cpu超過100%，例項偶爾出現卡住的現象； 1.原理：cpu消耗過大通常情況下都是有慢sql造成的，這裡的慢sql包括全表掃描，掃描資料量過大

讓天下沒有難用的資料庫 » RDS最佳實踐(五)

背景：RDS Mysql採用的binlog 格式預設為ROW，在Mysql 5.6的版本之前，Mysql每次列的修改（update）都需要記錄表中所有列的值。這樣就存在一個問題，如果表中包含很多的大欄位，表的單行長度就會非常長，這樣每次update就會導致大量的 binlog空間生成。針對這個問題，

讓天下沒有難用的資料庫 » RDS最佳實踐(四)

早上值班同事在旺旺群裡面貼了一條非常複雜的SQL，使用者從本地遷移到RDS Mysql出現嚴重效能下降，同樣的資料和表結構下，在本地的資料庫上只要不到1s的時間，但是在rds上好幾分鐘都沒響應。 碰到這類問題需要考慮以下一些因素： a.資料庫的版本不同（不同的版本優化器策略不一樣，或者異構資料庫間的

讓天下沒有難用的資料庫 » RDS

早上收到客戶反饋使用者操作非常的卡，聯絡幫助進行排查，下面總結關於sqlserver 問題排查的方法經驗： 方法一：ACTIVE MONITOR 通過sqlserver 的active monitor 來觀察當前系統的實時執行狀況 A. OVERVIEW 概況：CPU,WAITING TASK,DA

讓天下沒有難用的資料庫 » RDS最佳實踐(三)

上一篇文章中,我們介紹瞭如何快速的把本地自建的資料庫遷移入雲,那是不是把資料庫遷移到RDS後，使用者就什麼都不需要做了？比如RDS幫你的資料庫做到了高可用，在主庫出現down機後能夠快速切換到備庫，立刻恢復應用；每天會定時的備份資料和日誌，如果出現誤操作能夠幫你恢復到任意時間點；如果擔心黑客攻擊或者

讓天下沒有難用的資料庫 » RDS MySql支援online ddl

在日常和客戶溝通的過程中發現，他們在做mysql ddl變更的時候由於MySql本身的缺陷不支援online ddl，導致他們的業務不得不hang住一會兒，表越大，時間影響越長，所以期待有更好的解決方法；有些使用者也想了一些方法，比如通過主備切換的方法，先在備庫進行ddl，然後在通過主備切換到原主庫

讓天下沒有難用的資料庫 » RDS最佳實踐(二)

使用者在購買完RDS後，接下來就可以開始往RDS遷入資料了。在RDS剛剛對外提供服務的時候，使用者只能通過將自己的資料庫dump成為sql檔案，然後再將sql檔案source到RDS中去：資料遷移至RDS-MySQL之使用MySQLdump工具，資料遷移至RDS-SQLserver之利用SQL Server

讓天下沒有難用的資料庫 » RDS最佳實踐(一)

我該如何選擇RDS？我要購買多大規格的RDS？RDS的連線數，iops指的是什麼？上訴這些問題相信是每一個RDS使用者在開始使用的時候都會有這樣的疑問。首先我們要了解一下RDS的組成包括哪一些，從阿里雲官網的購買頁面中我們可以看到RDS包括了以下引數：資料庫型別，版本，儲存空間，規格：記憶體+連線數

讓天下沒有難用的資料庫 » RDS作業功能的支援

RDS最近將會支援資料庫的job功能,包括mysql的events和mssql的job. RDS在開放一個服務給使用者使用的時候,需要考慮非常的多因素,比如:   該服務所佔用的資源(記憶體,cpu等);   存在的bug(bug的存在可直接導致使用者在使用該服務上出現不當或者錯誤);   潛在的

讓天下沒有難用的資料庫 » 遷移到RDS應該注意的問題

相信大部分使用者在將自己本地的資料庫遷移到RDS的時候都會遇到各種各樣的問題，這裡總結一下在遷移過程中常見的問題，包括將本地資料庫（客戶資料庫）匯出成可執行的SQL檔案—–>匯入到遠端的RDS資料庫—->測試驗證. 案例一：使用者遷移到RDS，遇到檢視依賴的問題（MSSQL資料庫） 使用

讓天下沒有難用的資料庫 » 遷移到RDS

在使用者的日常遷移中常常採用以下的方法來完成遷移（以MYSQL為例）： 將使用者資料庫變為只讀； 全量dump MySQL成文字； 將MySQL資料遠端load到RDS； 將使用者的資料庫連線地址改為RDS提供的連線地址; 該方案比較簡單，易於維持資料一致性，但當用戶的資料量達到一個數量級別後（

讓天下沒有難用的資料庫 » 一個價值“千萬”的秒殺場景引數優化

秒殺最早來自天貓雙11各種商品的促銷活動中，現在已經有很多業務場景在使用，比如搶紅包，搶票等。其特點有三高：瞬時併發高，資料一致性高，熱點更新頻度高。這樣三高的場景下往往給資料庫造成極大的壓力，大量更新資料庫中的同一行，這樣必然會產生鎖等待，導致資料庫的效能急劇下降的問題，很容易容易出現雪崩效應。筆