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