一区二区三区在线-一区二区三区亚洲视频-一区二区三区亚洲-一区二区三区午夜-一区二区三区四区在线视频-一区二区三区四区在线免费观看

服務器之家:專注于服務器技術及軟件下載分享
分類導航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|數據庫技術|

服務器之家 - 數據庫 - Mysql - MySQL:mysqldump 100M的數據導入需要幾個小時?

MySQL:mysqldump 100M的數據導入需要幾個小時?

2024-01-01 01:00未知服務器之家 Mysql

這個問題相對簡單,但是第一次遇到這種問題,僅此記錄。問題主要是一個mysqldump導出也就100來M的文件,導入居然要幾個小時,更換多個實例后都很慢,文件大小如下: 當然這種可以重現的問題就再次導入看看為什么就可以了。

這個問題相對簡單,但是第一次遇到這種問題,僅此記錄。問題主要是一個mysqldump導出也就100來M的文件,導入居然要幾個小時,更換多個實例后都很慢,文件大小如下:

MySQL:mysqldump 100M的數據導入需要幾個小時?

當然這種可以重現的問題就再次導入看看為什么就可以了。

一、問題重現和分析

導入期間的信息如下:

OS狀態如下:

MySQL:mysqldump 100M的數據導入需要幾個小時?

可以看到導入session的線程的CPU非常高。

查看show processlist狀態:

MySQL:mysqldump 100M的數據導入需要幾個小時?

查看CPU調用火焰圖:

MySQL:mysqldump 100M的數據導入需要幾個小時?

耗用CPU最多的上層調用為mysql_alter_db。問題很明顯了,就是dump文件里面有大量的alter database 語句。這種語句耗用了大量的CPU,導致導入時間很長。

隨后查看文件中的alter database語句大概有5600個,每個就算1秒,也要5000多秒了,因此整個導入自然就慢了。

二、為什么有這么多的ALTER DATABASE語句

實際上在進行mysqldump的時候,如果發現存儲過程、自定義函數、觸發器等的字符集和庫的字符集不一致的時候就會調用switch_db_collation和restore_db_collation 函數,將庫的字符集切換后再建立存儲過程等對象,然后再將庫的字符集切換回去,實際上就是多了如下的輸出,

if (strcmp(current_db_cl_name, required_db_cl_name) != 0)
{...
    fprintf(sql_file, "ALTER DATABASE %s CHARACTER SET %s COLLATE %s %s\n",
            quoted_db_name, db_cl->csname, db_cl->m_coll_name, delimiter);
...
}

這樣這些對象的字符集就是導出庫一致的。

庫的字符集很明顯,而存儲過程、自定義函數、觸發器等獲取的是 Database Collation:

mysql> show create procedure get_order_total_amount2 \G
*************************** 1. row ***************************
           Procedure: get_order_total_amount2
...
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: utf8mb4_0900_ai_ci ---這里

比如:

  • 當前庫:utf8mb3
  • 存儲過程是:utf8mb4_0900_ai_ci

那么導出的語句就是:

alter database charset utf8mb4 ...;
create procedure...
alter database charset utf8mb3...;

下面是測試的片段:

ALTER DATABASE `chr` CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci ;
/*!50003 SET @saved_cs_client      = @@character_set_client */ ;
/*!50003 SET @saved_cs_results     = @@character_set_results */ ;
/*!50003 SET @saved_col_connection = @@collation_connection */ ;
/*!50003 SET character_set_client  = utf8mb4 */ ;
/*!50003 SET character_set_results = utf8mb4 */ ;
/*!50003 SET collation_connection  = utf8mb4_0900_ai_ci */ ;
/*!50003 SET @saved_sql_mode       = @@sql_mode */ ;
/*!50003 SET sql_mode              = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION' */ ;
DELIMITER ;;
CREATE DEFINER=`root`@`localhost` PROCEDURE `get_order_total_amount2`(IN order_id INT, OUT total_amount DECIMAL(10, 2))
BEGIN
  SELECT SUM(total_amount) INTO total_amount FROM orders WHERE order_id = order_id;
END ;;
DELIMITER ;
/*!50003 SET sql_mode              = @saved_sql_mode */ ;
/*!50003 SET character_set_client  = @saved_cs_client */ ;
/*!50003 SET character_set_results = @saved_cs_results */ ;
/*!50003 SET collation_connection  = @saved_col_connection */ ;
ALTER DATABASE `chr` CHARACTER SET utf8mb3 COLLATE utf8_general_ci ;

可以看到在存儲過程建立的前后有alter database 語句。如果有幾千個這樣的存儲過程,雖然數據不大,但是導入卻很很慢,因為耗用了太多CPU在alter database上,這些CPU耗用和導入的數據無關。

三、總結

這種問題出現,最可能的原因就是當庫初始化完成后,某天用 alter database修改了庫的字符集,導致導出的時候比對存儲過程、自定義函數、觸發器等的字符集和庫的字符集不一致出現了alter database語句,如果剛好存儲過程、自定義函數、觸發器等很多那么就可能很慢很慢。

延伸 · 閱讀

精彩推薦
主站蜘蛛池模板: 美女的隐私脱裤子无遮挡 | 美国女孩毛片 | 黄色wwwwww | 久久国产加勒比精品无码 | 国产在线麻豆波多野结衣 | 男男gaygays黑人 | 午夜爱爱片 | 2012中文字幕中字视频 | 国产成人福利免费视频 | 性做久久久久久久久浪潮 | 日本一区二区在线不卡 | 国产caoni555在线观看 | 亚洲视频在线免费观看 | 3黑人巨大vs北岛玲 3d肉浦团在线观看 3d动漫免费 | 紧身裙女教师波多野结衣 | 国产成人亚洲精品一区二区在线看 | 亚洲成年网站在线777 | 国产精品视频第一区二区三区 | 99草精品视频 | 亚洲阿v天堂2018在线观看 | 睡男神的这件小事小说在线阅读 | 日韩久久影院 | free性俄罗斯护士 | 无码人妻少妇色欲AV一区二区 | 国产高清在线精品一区二区 | 欧美精品一国产成人性影视 | 奇米777四色精品综合影院 | 国产精品一区二区三 | 青草香蕉精品视频在线观看 | 岛国在线播放v片免费 | 97精品国产高清在线看入口 | 高清在线观看免费入口 | 午夜视频一区二区 | 风间由美被义子中文字幕 | 日韩毛片基地一区二区三区 | 精品女同一区二区三区免费站 | 国产精品福利短视在线播放频 | 国产精品va在线观看无 | 国产精品高清一区二区三区 | 四虎影院精品 | 我的奶头被客人吸的又肿又红 |