建站
咨詢
售后
建站咨詢
新聞中心
SQL數(shù)據(jù)庫的打開速度是影響系統(tǒng)性能的重要因素之一，如果出現(xiàn)打開緩慢的情況就會對整個(gè)系統(tǒng)的運(yùn)行效率產(chǎn)生不良影響。為了解決這個(gè)問題，我們需要尋找合適的方法。
10年的金門網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。營銷型網(wǎng)站的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動調(diào)整金門建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。創(chuàng)新互聯(lián)建站從事“金門網(wǎng)站設(shè)計(jì)”,“金門網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
一、優(yōu)化查詢
1.優(yōu)化索引
索引是數(shù)據(jù)庫查詢速度的關(guān)鍵因素，正確的索引能夠使查詢速度提升很多倍，因此在設(shè)計(jì)數(shù)據(jù)庫時(shí)要注意選擇合適的索引。針對具體的查詢語句進(jìn)行優(yōu)化，可以通過expln來查看實(shí)際執(zhí)行計(jì)劃，從而進(jìn)一步優(yōu)化索引。
2.避免使用SELECT *
一些查詢都會使用SELECT *這樣的語句，雖然方便但效率極低。因?yàn)镾ELECT *會查詢整張表的所有列，在本人的實(shí)踐中，僅查詢所需列可以提高查詢速度50%以上。
3.使用子查詢
子查詢可以降低查詢所需的數(shù)據(jù)量，因?yàn)樗环祷刂付ㄐ械牧?，可以提高查詢速度。?yōu)化子查詢可以通過合理的使用JOIN和WHERE子句來實(shí)現(xiàn)。
二、優(yōu)化表格
1.切分大表
如果一個(gè)表格的數(shù)據(jù)過多，會導(dǎo)致查詢的速度變慢，因此需要將大表切分成小表。這種操作不僅在查詢方面有優(yōu)勢，而且在增量插入時(shí)也可以加快插入速度。
2.使用壓縮表
在數(shù)據(jù)庫中，很多數(shù)據(jù)的類型都是可壓縮的，比如說日期、時(shí)間等等。如果我們將這樣的數(shù)據(jù)保存在壓縮表中，可以減少數(shù)據(jù)的存儲空間，從而提高查詢速度。
3.限定字段類型
數(shù)據(jù)類型的選擇在數(shù)據(jù)庫優(yōu)化中起著關(guān)鍵作用，合適地選擇字段類型可以減少查詢時(shí)間和存儲空間。比如用INT類型的主鍵，就比用VARCHAR類型的主鍵查詢速度更快。
三、優(yōu)化服務(wù)器
1.服務(wù)器優(yōu)化
服務(wù)器的內(nèi)存、磁盤、CPU等方面的優(yōu)化也能夠提高數(shù)據(jù)庫的性能，首先需要確認(rèn)服務(wù)器配置是否合適，網(wǎng)絡(luò)連接是否暢通等等。
2.數(shù)據(jù)庫優(yōu)化
了解數(shù)據(jù)庫在使用過程中的技巧和注意事項(xiàng)，不僅可以提高數(shù)據(jù)功能的利用，也能夠避免因操作不當(dāng)造成的數(shù)據(jù)庫故障。
四、使用緩存
在數(shù)據(jù)處理的過程中，常常會涉及到重復(fù)查詢。為了減少重復(fù)查詢，可以通過緩存數(shù)據(jù)庫查詢的結(jié)果來提高查詢速度。這種做法可以節(jié)省很多查詢時(shí)間，從而讓系統(tǒng)更加高效。
優(yōu)化數(shù)據(jù)庫應(yīng)該是一個(gè)系統(tǒng)性的工程，需要綜合考慮不同的因素，尋找合適的方法來提高查詢速度。通過合理的索引、查詢和數(shù)據(jù)類型的選擇，以及服務(wù)器和數(shù)據(jù)庫的優(yōu)化，都能夠有效地減少查詢時(shí)間，加快數(shù)據(jù)庫的運(yùn)行速度。此外，使用緩存還能夠進(jìn)一步提高查詢效率。
相關(guān)問題拓展閱讀：
- 如何解決SQL查詢速度太慢?
如何解決SQL查詢速度太慢?
對于數(shù)據(jù)可以參照下面幾點(diǎn)
1、優(yōu)化SQL語句，SQL語句對查詢速度影響更大
2、對于經(jīng)常查詢的字凳物鎮(zhèn)段作索引。但是這樣棗粗會增加修改時(shí)的壓力
4、優(yōu)化SQLServer，比如給其分配固定的內(nèi)存，預(yù)先分配查詢內(nèi)存，調(diào)整CPU使用率等。
5、優(yōu)化硬件資源，比如使用更高的服務(wù)器或者硬盤，獨(dú)立安排數(shù)據(jù)庫的數(shù)據(jù)文件和索引文件，將數(shù)據(jù)文件分布于不同的物理硬盤上等等
6、考慮使用分布數(shù)據(jù)庫或者對大表進(jìn)行拆分
另外，2G的數(shù)據(jù)庫應(yīng)該不算很大了，我處理過18G的數(shù)據(jù)螞好庫，8000萬條記錄，查詢速度可以被接受
1. 執(zhí)行計(jì)劃中明明有使用到索引，為什么執(zhí)行還是這么慢？
2. 執(zhí)行計(jì)劃中顯示掃描行數(shù)為 644，為什么 slow log 中顯示 100 多萬行？
a. 我們先看執(zhí)行計(jì)劃，選擇的索引 “INDX_BIOM_ELOCK_TASK3(TASK_ID)”。結(jié)合 sql 來看，因?yàn)橛?“ORDER BY TASK_ID DESC” 子句，排序通常很慢，如果使用了文件排序性能會更差，優(yōu)化器選擇這個(gè)索引避免了排序。
那為什么不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡單，TASK_DATE 字段區(qū)分度太低了，走這個(gè)索引需要掃描的行數(shù)很大，而且還要進(jìn)行額外的排序，優(yōu)化器綜合判斷代價(jià)更大，所以就不選這個(gè)索引了。不過如果我們強(qiáng)制選擇這個(gè)索引缺純（用 force index 語法），會看到 SQL 執(zhí)行速度更快少于 10s，那是因?yàn)閮?yōu)化器基于代價(jià)的原則并不等價(jià)于執(zhí)行速度的快慢；
b. 再看執(zhí)行計(jì)劃中的 type:index，”index” 代表 “全索引掃描”，其實(shí)和全表掃描差不多，只是掃描的時(shí)候是按照索引次序進(jìn)行而不是行，主要優(yōu)點(diǎn)就是避免了排序，但是開銷仍然非常大。
Extra:Using where 也意味著掃描完索引后還需要回表進(jìn)行篩選。一般來說，鄭數(shù)得保證 type 至少達(dá)到 range 級別，更好能達(dá)到 ref。
在第 2 點(diǎn)中提到的“慢日志記錄Rows_examined:，看起來是全表掃描”，這里更正為“全索引掃描”，掃描行數(shù)確實(shí)等于表的行數(shù)；
c. 關(guān)于伏叢咐執(zhí)行計(jì)劃中：“rows：644”，其實(shí)這個(gè)只是估算值，并不準(zhǔn)確，我們分析慢 SQL 時(shí)判斷準(zhǔn)確的掃描行數(shù)應(yīng)該以 slow log 中的 Rows_examined 為準(zhǔn)。
4. 優(yōu)化建議：添加組合索引 IDX_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID)
優(yōu)化過程：
TASK_DATE 字段存在索引，但是選擇度很低，優(yōu)化器不會走這個(gè)索引，建議后續(xù)可以刪除這個(gè)索引：
select count(*),count(distinct TASK_DATE) from T_BIOMA_ELOCK_TASK;+++| count(*) | count(distinct TASK_DATE) |+++|| 223 |+++
在這個(gè) sql 中 REL_DEVID 字段從命名上看選擇度較高，通過下面 sql 來檢驗(yàn)確實(shí)如此：
select count(*),count(distinct REL_DEVID) from T_BIOMA_ELOCK_TASK;+++| count(*) | count(distinct REL_DEVID) |+++|||+++
由于有排序，所以得把 task_id 也加入到新建的索引中，REL_DEVID,task_id 組合選擇度 100%：
select count(*),count(distinct REL_DEVID,task_id) from T_BIOMA_ELOCK_TASK;+++| count(*) | count(distinct REL_DEVID,task_id) |+++|||+++
在測試環(huán)境添加 REL_DEVID，TASK_ID 組合索引，測試 sql 性能：alter table T_BIOMA_ELOCK_TASK add index idx_REL_DEVID_TASK_ID(REL_DEVID,TASK_ID);
添加索引后執(zhí)行計(jì)劃：
這里還要注意一點(diǎn)“隱式轉(zhuǎn)換”：REL_DEVID 字段數(shù)據(jù)類型為 varchar，需要在 sql 中加引號：AND T.REL_DEVID =xxx >> AND T.REL_DEVID = ‘xxx’
執(zhí)行時(shí)間從 10s+ 降到 毫秒級別：
1 row in set (0.00 sec)
結(jié)論
一個(gè)典型的 order by 查詢的優(yōu)化，添加更合適的索引可以避免性能問題：執(zhí)行計(jì)劃使用索引并不意味著就能執(zhí)行快。
SQL Server查詢速度慢的原因有很多，常見的有以下幾種：
1、沒有索引或者沒有用到索引(這是查詢慢最常見的問題，是程序設(shè)計(jì)的缺陷)
2、I/O吞吐量小，形成了瓶頸效應(yīng)。
3、沒有創(chuàng)建計(jì)算列導(dǎo)致查詢不優(yōu)化。
4、內(nèi)存不足陪搭告
5、網(wǎng)絡(luò)速度慢
6、查詢枝辯出的數(shù)據(jù)量過大(可以采用多次查詢，其他的方法降低數(shù)據(jù)量)
7、鎖或者死鎖(這也是查詢慢最常見的問題，是程序設(shè)計(jì)的缺陷)
8、sp_lock,sp_who，活動的用戶查看，原因是讀寫競爭蘆明資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優(yōu)化
把一個(gè)表族鋒分成幾個(gè)表，可以按，ID分開，比如,這樣分成多個(gè)表,當(dāng)然你可以用其它的方法分開,這樣的SELECT的速度會快兆行晌點(diǎn),其實(shí)你看到的耗時(shí)54秒,主要是輸出速度太慢了,不是帶巧查詢慢
建議不要使用select * 這樣數(shù)據(jù)量笑拍太大，可以加上select top 1000 * from hr_worktime
更好把一起不用的數(shù)據(jù)轉(zhuǎn)碰州羨移到備份庫，這里保留需要的最新數(shù)據(jù)即可跡猜。
sql數(shù)據(jù)庫打開慢的介紹就聊到這里吧，感謝你花時(shí)間閱讀本站內(nèi)容，更多關(guān)于sql數(shù)據(jù)庫打開慢,解決SQL數(shù)據(jù)庫打開慢的方法,如何解決SQL查詢速度太慢?的信息別忘了在本站進(jìn)行查找喔。
成都網(wǎng)站營銷推廣找創(chuàng)新互聯(lián)，全國分站站群網(wǎng)站搭建更好做SEO營銷。
創(chuàng)新互聯(lián)（www.cdcxhl.com）四川成都IDC基礎(chǔ)服務(wù)商，價(jià)格厚道。提供成都服務(wù)器托管租用、綿陽服務(wù)器租用托管、重慶服務(wù)器托管租用、貴陽服務(wù)器機(jī)房服務(wù)器托管租用。
文章標(biāo)題：解決SQL數(shù)據(jù)庫打開慢的方法 (sql數(shù)據(jù)庫打開慢)
網(wǎng)站URL：http://www.dlmjj.cn/article/djehchd.html
