执行SQL查询时,主要的几个瓶颈在于:CPU运算速度、内存缓存区大
执行SQL查询时,主要的几个瓶颈在于:CPU运算速度、内存缓存区大小、磁盘IO速度。而对于大数据量数据的查询,其瓶颈则一般集中于磁盘IO,以及内存缓存。那么为了提高SQL查询的效率,一方面我们需要考虑尽量减少查询设计的数据条目数——建立索引,设立分区;另一方面,我们也可以考虑切实减少数据表物理大小,从而减少IO大小。
在SQL Server 2008中,最新提供了一项功能“压缩(Compression)”,就是定位于减少数据表、索引物理大小。
设置压缩
在企业管理器中,在需要压缩的表或索引上右键选择Storage-》Manage Compression:
这里可以看到几点:
- 下方列表里列出了该表所有的分区,也就是可以同一张表的不同分区应用不同的压缩策略。
- 压缩方式(Compression Type)分为Row和Page两种。
行级压缩(Row):
一方面减少了动态长度字段元数据的大小(varchar、varbinary等),比如之前存储字段实际长度需要2bytes,压缩后只需要3bits。
另一方面也直接减少各字段存储内容的大小,比如存储数值1在一个int类型字段中,压缩后只占用了一个字节。
页级压缩(Page):能在各行间共享相同的数据,这里面包含两项技术:列前缀(Column Prefix)、页字典(Page Dictionary)。
列前缀可以让拥有同样前缀的字段值拥有类似外键一样的结构来存储相同的前缀和各自的其余部分。比如一张存储了一个网站所有页面URL的表,URL字段存储的值分别是‘www.example.com/a.html’,‘www.example.com/b.html’,‘www.example.com/c.html’,‘www.example.com/d.html’。则压缩后,它们同样的前缀‘www.example.com/’会被提取出来,而其余部分会被类似如下的形式存储‘1a.html’,‘1b.html’,‘1c.html’,‘1d.html’。
页字典则可以将在应用列前缀基础上的其余部分再次聚合存储,比如同样是一张存储了一个网站所有页面URL的表,假设有在表里里有多条URL字段的值相同,比如‘1a.html’,‘1b.html’,‘1c.html’,‘1b.html’,‘1a.html’,‘1a.html’,则通过页字典技术压缩后,实际存储在字段中的值会进一步减少为‘2’,‘3’,‘1c.html’(没有重复的字段值不会被压缩),‘3’,‘2’,‘2’。 - 点击“Calculate”后,会计算出表当前占用的空间大小,以及压缩需要的空间大小。注意这里与一般预想的不同,如果要对一张预存有数据但尚未压缩的表进行压缩,首先需要的是额外的空间大小。
执行压缩
设置好之后,就可以选择是生成脚本还是立即执行,一般压缩的执行时间受表原有数据多少以及选择压缩方式的影响。笔者对一张有上千万条记录的表做页级压缩,耗时在10分钟左右。
压缩完成之后查看数据库大小,会发现数据库的大小变大了!这也和在设置阶段计算出来的额外空间相关。但实际上这里大部分空间是预占的空间,并没有实际数据。如果需要节省磁盘空间,需要进一步执行收缩(Shrink)操作。
与Compression不同,Shrink用来释放数据库占据的没有利用的空间,一般用来对无用的日志文件收缩(如果操作频繁,日志文件很有可能大于数据库实际数据的大小)。这里我们对数据库文件(mdf)做Shrink操作,完成之后再看数据库的大小,果然减少了很多。笔者做压缩、Shrink之后,一般都能将数据库的大小减为原来的1/3~1/2左右。当然,具体压缩比率取决于压缩方式、压缩表的字段特点、压缩表占整个数据库数据的比重等。
注意事项
- 既然对表行了压缩,那么在执行查询时必然会有解压缩的过程。而这一过程会占用CPU时间,也就是我们在通过压缩减少了磁盘占用空间以及IO时间的同时,增大了CPU的消耗。所以在压缩前需要考虑清楚查询的瓶颈到底是磁盘IO还是内存还是CPU。而且如果表应用了压缩,类似建立索引,对于增删改等操作也会有一定的影响。所以同样要考虑应用在表上的操作到底以哪种为主。
- 各页面的压缩是独立进行的,页字典和列前缀也分别存储于各页内。而且压缩仅在数据页快满的时候进行,因为一个页的大小是固定的,压缩半页不会有性能上的提升。
- 数据库备份中也有Compression的选项,但这利用的是系统的文件压缩技术,而且只能应用于整个数据库上。
- 容易被忽略的是,索引也能被压缩,而且和表压缩独立,同样也会提升所有应用到索引的查询的性能。
- 在Shrink阶段,可能会造成大量的索引碎片,所以可以在Shrink完成之后重建或者重组织索引,但同时,这些操作也会造成数据库的体积变大……也就是,最小的数据库体积和最小碎片比率的索引是鱼与熊掌,不可兼得。

MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。

MySQL查询性能不佳的原因主要包括没有使用索引、查询优化器选择错误的执行计划、表设计不合理、数据量过大和锁竞争。1.没有索引导致查询缓慢,添加索引后可显著提升性能。2.使用EXPLAIN命令可以分析查询计划,找出优化器错误。3.重构表结构和优化JOIN条件可改善表设计问题。4.数据量大时,采用分区和分表策略。5.高并发环境下,优化事务和锁策略可减少锁竞争。

在數據庫優化中,應根據查詢需求選擇索引策略:1.當查詢涉及多個列且條件順序固定時,使用複合索引;2.當查詢涉及多個列但條件順序不固定時,使用多個單列索引。複合索引適用於優化多列查詢,單列索引則適合單列查詢。

要優化MySQL慢查詢,需使用slowquerylog和performance_schema:1.啟用slowquerylog並設置閾值,記錄慢查詢;2.利用performance_schema分析查詢執行細節,找出性能瓶頸並優化。

MySQL和SQL是開發者必備技能。 1.MySQL是開源的關係型數據庫管理系統,SQL是用於管理和操作數據庫的標準語言。 2.MySQL通過高效的數據存儲和檢索功能支持多種存儲引擎,SQL通過簡單語句完成複雜數據操作。 3.使用示例包括基本查詢和高級查詢,如按條件過濾和排序。 4.常見錯誤包括語法錯誤和性能問題,可通過檢查SQL語句和使用EXPLAIN命令優化。 5.性能優化技巧包括使用索引、避免全表掃描、優化JOIN操作和提升代碼可讀性。


熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

Atom編輯器mac版下載
最受歡迎的的開源編輯器

SecLists
SecLists是最終安全測試人員的伙伴。它是一個包含各種類型清單的集合,這些清單在安全評估過程中經常使用,而且都在一個地方。 SecLists透過方便地提供安全測試人員可能需要的所有列表,幫助提高安全測試的效率和生產力。清單類型包括使用者名稱、密碼、URL、模糊測試有效載荷、敏感資料模式、Web shell等等。測試人員只需將此儲存庫拉到新的測試機上,他就可以存取所需的每種類型的清單。

DVWA
Damn Vulnerable Web App (DVWA) 是一個PHP/MySQL的Web應用程序,非常容易受到攻擊。它的主要目標是成為安全專業人員在合法環境中測試自己的技能和工具的輔助工具,幫助Web開發人員更好地理解保護網路應用程式的過程,並幫助教師/學生在課堂環境中教授/學習Web應用程式安全性。 DVWA的目標是透過簡單直接的介面練習一些最常見的Web漏洞,難度各不相同。請注意,該軟體中

SublimeText3 Linux新版
SublimeText3 Linux最新版

EditPlus 中文破解版
體積小,語法高亮,不支援程式碼提示功能