mysql use db后很卡解决_MySQL
bitsCN.com
mysql use db后很卡解决
平时自己使用的一台mysql,use db之后,总是感觉很卡,按完回车要快1s才能返回。觉得有什么蹊跷,就打开了general log,发现简单的use test,mysql实际执行了很多内容:
Sql代码
130603 16:02:11 2 Query SELECT DATABASE()
2 Init DB test
2 Query show databases
2 Query show tables
2 Field List b
2 Field List bmw
2 Field List http_auth
2 Field List perf_machine
2 Field List t
2 Field List t1
2 Field List t2
2 Field List t5
2 Field List t_max_col
2 Field List tb
2 Field List tbcsv
2 Field List tbmemory
2 Field List tbmyisam
2 Field List tc
2 Field List total
2 Field List tt
而简单的show tables,show databases, select database(),show tables from test,实际都只对应一条generallog。
Sql代码
130603 16:17:12 2 Query show tables
130603 16:17:28 2 Query show databases
130603 16:17:48 2 Query SELECT DATABASE()
130603 16:19:44 3 Query show tables from test
从general log可以看到 一条use test,实际执行了多次dispatch_command(),使用gdb对general_log_write()设置断点,实际执行如下:
COM_QUERY,对应的sql是 SELECT DATABASE(),调用路径为:handle_one_connection(sql_connect.cc)->do_command(sql_parse.cc)->dispatch_command(sql_parse.cc,command=COM_QUERY,packet="SELECT DATABASE()");
COM_INIT_DB,调用路径为:handle_one_connection(sql_connect.cc)->do_command(sql_parse.cc)->dispatch_command(sql_parse.cc,command=COM_INIT_DB,packet="test");
COM_QUERY,对应的sql是 show databases,调用路径为:handle_one_connection(sql_connect.cc)->do_command(sql_parse.cc)->dispatch_command(sql_parse.cc,command=COM_QUERY,packet="show databases");
COM_QUERY,对应的sql是show tables,调用路径为:handle_one_connection(sql_connect.cc)->do_command(sql_parse.cc)->dispatch_command(sql_parse.cc,command=COM_QUERY,packet="show tables");
COM_FIELD_LIST,调用路径为:handle_one_connection(sql_connect.cc)->do_command(sql_parse.cc)->dispatch_command(sql_parse.cc,command=COM_FIELD_LIST,packet="columns_priv")。此处是n次调用(n为被use的schema下的表的个数,每次调用的时候,pachet内容即为表名);
因此在被use的schema下的表比较多的时候,自然会显得有些卡了(连续use同样的schema,则第二次use,则只会有COM_QUERY和COM_INIT_DB的过程), 为了避免use db后很卡,my.cnf里加上 no-auto-rehash;或者用mysql client连接的时候加上-A选项。
bitsCN.com

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

MySQL啟動失敗的原因有多種,可以通過檢查錯誤日誌進行診斷。常見原因包括端口衝突(檢查端口占用情況並修改配置)、權限問題(檢查服務運行用戶權限)、配置文件錯誤(檢查參數設置)、數據目錄損壞(恢復數據或重建表空間)、InnoDB表空間問題(檢查ibdata1文件)、插件加載失敗(檢查錯誤日誌)。解決問題時應根據錯誤日誌進行分析,找到問題的根源,並養成定期備份數據的習慣,以預防和解決問題。

MySQL 可在無需網絡連接的情況下運行,進行基本的數據存儲和管理。但是,對於與其他系統交互、遠程訪問或使用高級功能(如復制和集群)的情況,則需要網絡連接。此外,安全措施(如防火牆)、性能優化(選擇合適的網絡連接)和數據備份對於連接到互聯網的 MySQL 數據庫至關重要。

MySQL使用共享鎖和排他鎖管理並發,提供表鎖、行鎖和頁鎖三種鎖類型。行鎖可提高並發性,使用FOR UPDATE語句可給行加排他鎖。悲觀鎖假設衝突,樂觀鎖通過版本號判斷數據修改。常見鎖表問題表現為查詢緩慢,使用SHOW PROCESSLIST命令查看鎖持有的查詢。優化措施包括選擇合適索引、減少事務範圍、批量操作和優化SQL語句。

MySQL數據庫操作中,字符串處理是不可避免的環節。 SUBSTRING_INDEX函數正是為此而設計的,它能高效地根據分隔符提取子字符串。 SUBSTRING_INDEX函數應用示例以下示例展示了SUBSTRING_INDEX函數的靈活性和實用性:從URL中提取特定部分例如,提取域名:SELECTSUBSTRING_INDEX('www.mysql.com','.',2);提取文件擴展名輕鬆獲取文件擴展名:SELECTSUBSTRING_INDEX('file.pdf','.',-1);處理不存在

MySQL 主鍵不可以為空,因為主鍵是唯一標識數據庫中每一行的關鍵屬性,如果主鍵可以為空,則無法唯一標識記錄,將會導致數據混亂。使用自增整型列或 UUID 作為主鍵時,應考慮效率和空間佔用等因素,選擇合適的方案。

MySQL 可返回 JSON 數據。 JSON_EXTRACT 函數可提取字段值。對於復雜查詢,可考慮使用 WHERE 子句過濾 JSON 數據,但需注意其性能影響。 MySQL 對 JSON 的支持在不斷增強,建議關注最新版本及功能。

對於生產環境,通常需要一台服務器來運行 MySQL,原因包括性能、可靠性、安全性和可擴展性。服務器通常擁有更強大的硬件、冗餘配置和更嚴格的安全措施。對於小型、低負載應用,可在本地機器運行 MySQL,但需謹慎考慮資源消耗、安全風險和維護成本。如需更高的可靠性和安全性,應將 MySQL 部署到雲服務器或其他服務器上。選擇合適的服務器配置需要根據應用負載和數據量進行評估。

MySQL 和 MariaDB 可以共存,但需要謹慎配置。關鍵在於為每個數據庫分配不同的端口號和數據目錄,並調整內存分配和緩存大小等參數。連接池、應用程序配置和版本差異也需要考慮,需要仔細測試和規劃以避免陷阱。在資源有限的情況下,同時運行兩個數據庫可能會導致性能問題。
