建站
咨詢
售后
建站咨詢
新聞中心
在當(dāng)今信息化社會(huì)中，小型數(shù)據(jù)庫(kù)被廣泛應(yīng)用于各個(gè)領(lǐng)域，如財(cái)務(wù)、客戶、銷售等，為企業(yè)管理提供了方便。然而，隨著數(shù)據(jù)的不斷增加，小型數(shù)據(jù)庫(kù)的搜索速度卻越來越慢，這使得企業(yè)在管理過程中出現(xiàn)了很多問題，因此如何優(yōu)化小型數(shù)據(jù)庫(kù)的搜索速度，成為了當(dāng)前熱門話題。下面將從幾個(gè)方面詳細(xì)介紹如何考慮小型數(shù)據(jù)庫(kù)的搜索速度問題，讓企業(yè)管理更加便利。
一、索引策略優(yōu)化
索引是提高小型數(shù)據(jù)庫(kù)搜索速度的最基本的手段，索引策略的優(yōu)化可以使得數(shù)據(jù)庫(kù)的查詢操作更加高效。這里提幾個(gè)最常用的索引策略：
1.主鍵索引
主鍵索引是一種非常重要的索引，它是一種唯一標(biāo)識(shí)表中每一行數(shù)據(jù)的索引，在創(chuàng)建表的時(shí)候就要確定主鍵，構(gòu)建主鍵索引。使用主鍵索引可快速提取所需記錄，提高數(shù)據(jù)庫(kù)的搜索速度。
2.唯一索引
唯一索引的定義可以限定某一列不會(huì)出現(xiàn)重復(fù)值，不同于主鍵索引，不要求所有的記錄都有索引，可根據(jù)實(shí)際情況選擇創(chuàng)建唯一索引，提高數(shù)據(jù)庫(kù)的搜索速度。
3.聚簇索引
聚簇索引是按照表中的某個(gè)字段來排序，使數(shù)據(jù)存儲(chǔ)在物理上的相鄰位置，可以避免數(shù)據(jù)的分散和碎片化，提高搜索速度，但如果不合理使用會(huì)影響數(shù)據(jù)庫(kù)的查詢性能。
二、優(yōu)化查詢語句
經(jīng)過索引策略的調(diào)整，再?gòu)膕ql查詢語句上進(jìn)行優(yōu)化也是一種提高數(shù)據(jù)庫(kù)查詢速度的方式。
1.把多個(gè)相關(guān)的查詢的語句，合并為更少的語句。
2.盡可能的避免使用“非等值”查詢，即使用不等于、大于、小于等操作符時(shí)，數(shù)據(jù)庫(kù)的搜索速度會(huì)大大降低。
3.應(yīng)盡量避免在查詢中使用非條件、非限制性的操作，如ORDER BY、GROUP BY等操作，這些操作會(huì)消耗數(shù)據(jù)庫(kù)的大量資源，導(dǎo)致搜索速度下降。
4.應(yīng)該采用“前綴匹配原則”，把最常用和最常查詢的字段放在語句前面，可提高數(shù)據(jù)檢索的效率。
三、定期表的優(yōu)化和維護(hù)
隨著數(shù)據(jù)量會(huì)越來越大，表中數(shù)據(jù)的增加會(huì)致使數(shù)據(jù)庫(kù)搜索速度降低，當(dāng)數(shù)據(jù)達(dá)到一定規(guī)模后，數(shù)據(jù)庫(kù)的性能會(huì)明顯下降。我們需要通過對(duì)小型數(shù)據(jù)庫(kù)表的優(yōu)化和維護(hù)，使其能夠充分發(fā)揮出搜索性能。
1.將不常用或者過期的數(shù)據(jù)移動(dòng)到其他表中，以減少表內(nèi)數(shù)據(jù)量。
2.定期進(jìn)行數(shù)據(jù)備份，以便數(shù)據(jù)誤刪除后恢復(fù)
3.為表添加自動(dòng)增長(zhǎng)屬性，防止表容量過大影響搜索速度。
4.清除表內(nèi)垃圾數(shù)據(jù)，可以用delete from tablename where fieldname = NULL指令來清除字段中的null值。
小結(jié)
在應(yīng)用小型數(shù)據(jù)庫(kù)的過程中，要注意合理的索引策略的使用，充分利用索引數(shù)據(jù)庫(kù)的行數(shù)，同時(shí)，對(duì)SQL語句進(jìn)行優(yōu)化，對(duì)于表的優(yōu)化和維護(hù)也不能忽視。通過以上幾點(diǎn)優(yōu)化，可以有效提高小型數(shù)據(jù)庫(kù)的搜索速度，使得企業(yè)管理更加便利。同時(shí)，小型數(shù)據(jù)庫(kù)的使用也需要注意數(shù)據(jù)的安全性，加強(qiáng)對(duì)小型數(shù)據(jù)庫(kù)的信息安全管控，保護(hù)數(shù)據(jù)資產(chǎn)的安全，是企業(yè)管理者不得不要考慮的問題。
相關(guān)問題拓展閱讀：
- mysql數(shù)據(jù)庫(kù)有100萬+數(shù)據(jù)，查詢起來很慢了，如何優(yōu)化
- 如何解決SQL查詢速度太慢?
mysql數(shù)據(jù)庫(kù)有100萬+數(shù)據(jù)，查詢起來很慢了，如何優(yōu)化
你好，你可以根據(jù)條件去添加索引，例如：
一、
所有mysql索引列類型都猛侍可以被索引，對(duì)來相關(guān)類使用索引可以提高select查詢性能，根據(jù)mysql索引數(shù)，可以是更大索引與最小索引，每種存儲(chǔ)引擎對(duì)每個(gè)表的至少支持16的索引?？偹饕L(zhǎng)度為256字節(jié)。
mysim和innodb存儲(chǔ)引擎的表默認(rèn)創(chuàng)建索引都是btree索引，目前mysql還不支持函數(shù)索引，但支持前緣索引，對(duì)字段前N個(gè)字符創(chuàng)建索引
二、mysql創(chuàng)建索引語法
Create index indexname on tablename( tablenamecol)
index_col_name:
col_name
如果你創(chuàng)建索引時(shí)搞錯(cuò)了，需要修改mysql索引我們可以用alert來修改索引，語法與create index創(chuàng)建索引差不多，我們就不說了，可以查看行穗相關(guān)手冊(cè)。
下面我們來看一個(gè)關(guān)于mysql創(chuàng)建索引實(shí)例教程。
mysql>create index 檔知卜cityname on city(city(2));
Query Ok,600 rows affected (0.26 sec)
Records :600 Duplicates:0 Warings 0:
我們現(xiàn)在來以city為條件進(jìn)行查詢，如下面。
->explain select * from city where city =’
www.111cn.net’ G
id:1
……
possible_keys:cityname
key:cityname
好了，現(xiàn)在我們來看看mysql刪除索引等實(shí)例
Drop indexname on tablename
實(shí)例，我現(xiàn)在要?jiǎng)h除剛才創(chuàng)建city索引
>drop index cityname on city;
Query ok, …..
如何解決SQL查詢速度太慢?
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” 子句，排序通常很慢，如果使用了文件排序性能會(huì)更差，優(yōu)化器選擇這個(gè)索引避免了排序。
那為什么不選 possible_keys:INDX_BIOM_ELOCK_TASK 呢？原因也很簡(jiǎn)單，TASK_DATE 字段區(qū)分度太低了，走這個(gè)索引需要掃描的行數(shù)很大，而且還要進(jìn)行額外的排序，優(yōu)化器綜合判斷代價(jià)更大，所以就不選這個(gè)索引了。不過如果我們強(qiáng)制選擇這個(gè)索引缺純（用 force index 語法），會(huì)看到 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 級(jí)別，更好能達(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)化器不會(huì)走這個(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) |+++|||+++
在測(cè)試環(huán)境添加 REL_DEVID，TASK_ID 組合索引，測(cè)試 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 中加引號(hào)：AND T.REL_DEVID =xxx >> AND T.REL_DEVID = ‘xxx’
執(zhí)行時(shí)間從 10s+ 降到 毫秒級(jí)別：
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，活動(dòng)的用戶查看，原因是讀寫競(jìng)爭(zhēng)蘆明資源。
9、返回了不必要的行和列
10、查詢語句不好，沒有優(yōu)化
對(duì)于數(shù)據(jù)可以參照下面幾點(diǎn)
1、優(yōu)化SQL語句，SQL語句對(duì)查詢速度影響更大
2、對(duì)于經(jīng)常查詢的字凳物鎮(zhèn)段作索引。但是這樣棗粗會(huì)增加修改時(shí)的壓力
4、優(yōu)化SQLServer，比如給其分配固定的內(nèi)存，預(yù)先分配查詢內(nèi)存，調(diào)整CPU使用率等。
5、優(yōu)化硬件資源，比如使用更高的服務(wù)器或者硬盤，獨(dú)立安排數(shù)據(jù)庫(kù)的數(shù)據(jù)文件和索引文件，將數(shù)據(jù)文件分布于不同的物理硬盤上等等
6、考慮使用分布數(shù)據(jù)庫(kù)或者對(duì)大表進(jìn)行拆分
另外，2G的數(shù)據(jù)庫(kù)應(yīng)該不算很大了，我處理過18G的數(shù)據(jù)螞好庫(kù)，8000萬條記錄，查詢速度可以被接受
把一個(gè)表族鋒分成幾個(gè)表，可以按，ID分開，比如,這樣分成多個(gè)表,當(dāng)然你可以用其它的方法分開,這樣的SELECT的速度會(huì)快兆行晌點(diǎn),其實(shí)你看到的耗時(shí)54秒,主要是輸出速度太慢了,不是帶巧查詢慢
建議不要使用select * 這樣數(shù)據(jù)量笑拍太大，可以加上select top 1000 * from hr_worktime
更好把一起不用的數(shù)據(jù)轉(zhuǎn)碰州羨移到備份庫(kù)，這里保留需要的最新數(shù)據(jù)即可跡猜。
關(guān)于數(shù)據(jù)不多但查找數(shù)據(jù)庫(kù)很慢的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
香港服務(wù)器選創(chuàng)新互聯(lián)，2H2G首月10元開通。
創(chuàng)新互聯(lián)（www.cdcxhl.com）互聯(lián)網(wǎng)服務(wù)提供商,擁有超過10年的服務(wù)器租用、服務(wù)器托管、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗(yàn)。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名注冊(cè)、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。
本文名稱：如何優(yōu)化小型數(shù)據(jù)庫(kù)的搜索速度？(數(shù)據(jù)不多但查找數(shù)據(jù)庫(kù)很慢)
文章分享：http://www.dlmjj.cn/article/djdgjce.html
