sql server搜索相當(dāng)慢怎么處理？？？

到網(wǎng)上找一個(gè)內(nèi)存管理工具，對(duì)內(nèi)存進(jìn)行定時(shí)管理，比如你的機(jī)器從重啟到內(nèi)存被SQL占用完要1小時(shí)，你可以把時(shí)間設(shè)置成30－45分鐘清理一清內(nèi)存，也可能用自動(dòng)的那種，可能30秒一次吧。

曲沃ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)建站的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！

要不然把你的SQL占用內(nèi)存設(shè)為固定值，可能是你物理內(nèi)存的50%左右，看你的具體情況了

sql server數(shù)據(jù)庫查詢慢怎么優(yōu)化

在安裝有SQLServer數(shù)據(jù)庫的計(jì)算機(jī)上，我們?cè)谑褂脭?shù)據(jù)庫的過程中，有時(shí)候會(huì)在任務(wù)管理器里發(fā)現(xiàn)sqlservr.exe這個(gè)進(jìn)程的內(nèi)存和CPU占用率較高。

接下來我們來看一下，如何解決上面這個(gè)問題，需要設(shè)置SQLServer數(shù)據(jù)庫的內(nèi)存配置。登錄數(shù)據(jù)庫，這里使用的是SQLServer2008,右鍵點(diǎn)擊最上方的服務(wù)器名，在彈出的菜單中，點(diǎn)擊【屬性】

打開服務(wù)器屬性窗口。默認(rèn)顯示的是第一項(xiàng)【常規(guī)】內(nèi)容，點(diǎn)擊第二項(xiàng)【內(nèi)存】進(jìn)行內(nèi)存配置。

點(diǎn)擊【內(nèi)存】后，打開服務(wù)器內(nèi)存選項(xiàng)配置界面。這里的【使用AWE分配內(nèi)存】可以對(duì)內(nèi)存進(jìn)行擴(kuò)展支持，我們要做的是更改下方的最大服務(wù)器內(nèi)存。這個(gè)數(shù)值根據(jù)自己服務(wù)器內(nèi)存大小來做適當(dāng)設(shè)置。

5

個(gè)人建議設(shè)置本機(jī)內(nèi)存的一半或稍微高一點(diǎn)，如機(jī)器內(nèi)存為2G，那么我們這里填寫1000。需要注意的是內(nèi)存設(shè)置調(diào)小以后，在數(shù)據(jù)庫執(zhí)行較復(fù)雜SQL語句的時(shí)候，可能會(huì)比較慢，出現(xiàn)這種情況，我們?cè)龠m當(dāng)上調(diào)最大內(nèi)存配置大小。

如何解決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 呢？原因也很簡單，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)行篩選。一般來說，得保證 type 至少達(dá)到 range 級(jí)別，最好能達(dá)到 ref。

在第 2 點(diǎn)中提到的“慢日志記錄Rows_examined: 1161559，看起來是全表掃描”，這里更正為“全索引掃描”，掃描行數(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) |+------------+---------------------------+| 1161559 | 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) |+----------+---------------------------+| 1161559 | 62235 |+----------+---------------------------+

由于有排序，所以得把 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) |+----------+-----------------------------------+| 1161559 | 1161559 |+----------+-----------------------------------+

在測試環(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 中加引號(hào)：AND T.REL_DEVID = 000000025xxx AND T.REL_DEVID = '000000025xxx'

執(zhí)行時(shí)間從 10s+ 降到 毫秒級(jí)別：

1 row in set (0.00 sec)

結(jié)論

一個(gè)典型的 order by 查詢的優(yōu)化，添加更合適的索引可以避免性能問題：執(zhí)行計(jì)劃使用索引并不意味著就能執(zhí)行快。