A. 4.IDEA 插件載入很慢 解決方法
原因分析
IDEA的模塊系統載入不出來，是由於IDEA的網路安全機製造成的，類似於windows的防火牆，IDEA誤認為你的網路不安全，不給你連接，本質為公司的網路被IDEA認為不安全，具體IDEA為什麼會這么認為，原因暫時我還不知道。
解決辦法
打開 Setting--》Appearance & Behavior --》Syetem Setting --》Updates ，將 Use secure connection 的勾選去掉。如下圖所示配置，然後重新搜索plugins，已經可以正常連網搜索了。
B. 使用IDEA開發，做單步調試速度巨慢，何解
我覺得運行慢的問題從四個方面講吧：
1、是否給IDEA分配了足夠的內存空間
2、是否對IDEA的Setting做過相關優化
3、IDEA的項目緩存如「.IntelliJIdea90」目錄是否和你的項目在同一個磁碟，因為默認IDEA會放到C盤，如果你項目工程在D盤，那麼創建、讀取、重建索引往往是文件和讀取，這里建議IDEA的安裝目錄、項目目錄、和索引緩存目錄放在同一個磁碟。
4、IDEA對IO操作比較頻繁，其實可以嘗試把機器硬碟升級為固態硬碟
我大致能想到這幾點，歡迎大家補充，謝謝
C. IntelliJ IDEA CVS怎麼那麼慢
解決了嗎？我這也遇到這樣的問題了巨慢～～甚至我創建的項目import到伺服器都慢的沒反應了
最近我解決了，看看能不能幫到別人，博客：
網頁鏈接
D. 關於idea運行很慢的解決辦法
在實際開發中，隨著project的增大，idea使用過程中逐漸出現了各種各樣的運行慢問題。博主就針對這些問題做了一個綜合，方便讀者各自對症下葯。
引起idea慢的原因多種多樣，我們需要有步驟的慢慢排查。
E. 執行計劃之誤區，為什麼cost很小，sql卻跑得很慢
理論上是 cost值越大,SQL的執行計劃就不好.
但是還有一個前提，就是你的表的分析數據要正確。
cost 值的計算，是根據資料庫表的統計信息來計算的。
例如 你有一個 一百萬行的表 ABC。 在 A 列上面有一個索引。
你
SELECT SUM(B) FROM ABC WHERE A = 100
在資料庫沒有表/索引的 相關統計信息的情況下， 這個 cost 確實是估計出來的一個大概的值。偏差可能 與這個表中的 A=100 的數量有多少相關。
比如 100萬條記錄裡面， A=100 的數據只有一條 / A=100 的數據只有 十萬條。 執行的時間可是差很多的。
但是如果表/索引 沒有被分析過， 資料庫對於
SELECT SUM(B) FROM ABC WHERE A = 100
還是
SELECT SUM(B) FROM ABC WHERE A = 1000
查詢的計劃，是一樣的。
但是如果你的 表/索引， 是已經分析過了的， 那麼 cost 所反映出來的值， 可能更精確一些。
因為在分析的時候，就能知道 A=100 的數據只有一條 還是有 十萬條。
資料庫可以根據需要，選擇最佳的查詢方案來進行處理。
假如 那一百萬條數據中， A=100 的數據只有一條 ，而 A=1000的數據，有 八十萬條。
那麼很可能
SELECT SUM(B) FROM ABC WHERE A = 100
使用索引的查詢計劃
而
SELECT SUM(B) FROM ABC WHERE A = 1000
使用全表掃描的查詢計劃。
F. idea的open目錄超級慢的原因及解決方法
一段時間以來，idea打開目錄都超級慢，可是打開以後確沒有什麼異常的問題，只是打開的時候慢，有時候需要20秒左右。網路了一下竟然不少人有類似的問題，原因是在open folder的時候，idea調用了另外兩個exe文件，這樣的調用會被殺毒軟體等監控，進行掃描，所以造成速度非常慢得的問題。
解決：
將windows自帶的安全防禦關閉，並且將項目目錄和idea的目錄鍵入360或者騰訊管家的信任區。這樣就能解決了。這個問題困擾我很久。終於解決，記錄一下。
G. oracle 9i資料庫白天跑的很正常，一到晚上就出現執行sql緩慢超時的情況，sql就是一般的插入和查詢語句。
晚上那些個自動執行的job就起來了，不建議普通用戶佔用晚上的空間時間。
你們每天在用的數據都是靠晚上運行的batch跑出來的
H. 如何解決SQL Server查詢速度緩慢的問題
1.查詢的模糊匹配
盡量避免在一個復雜查詢裡面使用 LIKE '%parm1%'——紅色標識位置的百分號會導致相關列的索引無法使用，最好不要用.
解決辦法:
其實只需要對該腳本略做改進，查詢速度便會提高近百倍。改進方法如下：
a、修改前台程序——把查詢條件的供應商名稱一欄由原來的文本輸入改為下拉列表，用戶模糊輸入供應商名稱時，直接在前台就幫忙定位到具體的供應商，這樣在調用後台程序時，這列就可以直接用等於來關聯了。
b、直接修改後台——根據輸入條件，先查出符合條件的供應商，並把相關記錄保存在一個臨時表裡頭，然後再用臨時表去做復雜關聯
2.索引問題
在做性能跟蹤分析過程中，經常發現有不少後台程序的性能問題是因為缺少合適索引造成的，有些表甚至一個索引都沒有。這種情況往往都是因為在設計表時，沒去定義索引，而開發初期，由於表記錄很少，索引創建與否，可能對性能沒啥影響，開發人員因此也未多加重視。然一旦程序發布到生產環境，隨著時間的推移，表記錄越來越多
這時缺少索引，對性能的影響便會越來越大了。
這個問題需要資料庫設計人員和開發人員共同關注
法則：不要在建立的索引的數據列上進行下列操作:
◆避免對索引欄位進行計算、函數、類型轉換
◆避免在索引欄位上使用not，<>，!=
◆避免在索引列上使用空值、IS NULL和IS NOT NULL
3.復雜操作
部分UPDATE、SELECT 語句寫得很復雜（經常嵌套多級子查詢）——可以考慮適當拆成幾步，先生成一些臨時數據表，再進行關聯操作
4.update
同一個表的修改在一個過程里出現好幾十次，如：
update table1
set col1=...
where col2=...;
update table1
set col1=...
where col2=...
......
象這類腳本其實可以很簡單就整合在一個UPDATE語句來完成（前些時候在協助xxx項目做性能問題分析時就發現存在這種情況）
5.在可以使用UNION ALL的語句里，使用了UNION
UNION 因為會將各查詢子集的記錄做比較，故比起UNIONALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重復記錄，但由於腳本的特殊性，不可能存在重復記錄，這時便應該使用UNION ALL，如xx模塊的某個查詢程序就曾經存在這種情況，見，由於語句的特殊性，在這個腳本中幾個子集的記錄絕對不可能重復，故可以改用UNION ALL）
6.在WHERE 語句中，盡量避免對索引欄位進行計算操作
這個常識相信絕大部分開發人員都應該知道，但仍有不少人這么使用，我想其中一個最主要的原因可能是為了編寫寫簡單而損害了性能，那就不可取了
9月份在對XX系統做性能分析時發現，有大量的後台程序存在類似用法，如：
......
where trunc(create_date)=trunc(:date1)
雖然已對create_date 欄位建了索引，但由於加了TRUNC，使得索引無法用上。此處正確的寫法應該是
where create_date>=trunc(:date1) andcreate_date
或者是
where create_date between trunc(:date1) andtrunc(:date1)+1-1/(24*60*60)
注意：因between 的范圍是個閉區間（greater than or equal to low value and less than or equal to highvalue.），
故嚴格意義上應該再減去一個趨於0的小數，這里暫且設置成減去1秒（1/(24*60*60)），如果不要求這么精確的話，可以略掉這步。
7.對Where 語句的法則
7.1避免在WHERE子句中使用in，not in，or 或者having。
可以使用 exist 和not exist代替 in和not in。
可以使用表鏈接代替 exist。Having可以用where代替，如果無法代替可以分兩步處理。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)
優化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)
7.2 不要以字元格式聲明數字，要以數字格式聲明字元值。（日期同樣）否則會使索引無效，產生全表掃描。
例子使用：
SELECT emp.ename, emp.jobFROM emp WHERE emp.empno = 7369;
不要使用：SELECT emp.ename,emp.job FROM emp WHERE emp.empno = 『7369』
8.對Select語句的法則
在應用程序、包和過程中限制使用select * from table這種方式。看下面例子
使用SELECT empno,ename,categoryFROM emp WHERE empno = '7369『
而不要使用SELECT * FROM empWHERE empno = '7369'
9. 排序
避免使用耗費資源的操作，帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啟動SQL引擎 執行，耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序
10.臨時表
慎重使用臨時表可以極大的提高系統性能
所謂的優化就是WHERE子句利用了索引，不可優化即發生了表掃描或額外開銷。經驗顯示，SQL Server性能的最大改進得益於邏輯的資料庫設計、索引設計和查詢設計方面。反過來說，最大的性能問題常常是由其中這些相同方面中的不足引起的。其實SQL優化的實質就是在結果正確的前提下，用優化器可以識別的語句，充份利用索引，減少表掃描的I/O次數，盡量避免表搜索的發生。
其實SQL的性能優化是一個復雜的過程，上述這些只是在應用層次的一種體現，深入研究還會涉及資料庫層的資源配置、網路層的流量控制以及操作系統層的總體設計。
I. 裝完SQL SERVER後開機變得很慢，怎麼解決
在sql server安裝之後就算是不運行這種管理器的主程序，也會在操作系統之中安裝一些服務，這種服務就是sql server的資料庫服務。
而這種服務一旦開啟在操作系統開機的時候系統就是會默認啟動多個sqlserver.exe進程。
如果操作系統是windows7操作系統的話，那麼其啟動的進程大約是在四個左右。
每一個進程都是會佔用超過30MB的內存空間，在某些情況之下佔用的內存資源還是會更多。
這就是安裝了sql server之後操作系統變得十分卡頓的原因。
如果在最開始開機的時候就是關閉這些應用程序的話就是會發現系統立馬就是會快速很多。
J. sql語句跑不出來是什麼原因
如果你覺得關聯沒問題，那就是你的數據有問題
看看你用到的幾個欄位都是什麼類型，是數字還是字元，如果字元的話看是varchar還是char
這個我怕你查的慢，我你好了，查收，瀏覽器右上角