1. 如何解決mysql 查詢和更新速度慢
索引是快速搜索的關鍵。MySQL索引的建立對於mysql的高效運行是很重要的。下面幾種常見的MySQL索引類型。
在資料庫表中，對欄位建立索引可以大大提高查詢速度。假如我們創建了一個 mytable表：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL ); 我們隨機向裡面插入了10000條記錄，其中有一條：5555,admin。
在查找username="admin"的記錄 SELECT * FROMmytable WHERE username='admin';時，如果在username上已經建立了索引，MySQL無須任何掃描，即准確可找到該記錄。相反，MySQL會掃描所有記錄，即要查詢10000條記錄。
索引分單列索引和組合索引。單列索引，即一個索引只包含單個列，一個表可以有多個單列索引，但這不是組合索引。組合索引，即一個索包含多個列。
MySQL索引類型包括：
（1）普通索引
這是最基本的索引，它沒有任何限制。它有以下幾種創建方式：
◆創建索引
CREATE INDEX indexName ONmytable(username(length)); 如果是CHAR，VARCHAR類型，length可以小於欄位實際長度；如果是BLOB和TEXT類型，必須指定 length，下同。
◆修改表結構
ALTER mytable ADD INDEX [indexName] ON(username(length)) ◆創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); 刪除索引的語法：
DROP INDEX [indexName] ON mytable;
（2）唯一索引
它與前面的普通索引類似，不同的就是：索引列的值必須唯一，但允許有空值。如果是組合索引，則列值的組合必須唯一。它有以下幾種創建方式：
◆創建索引
CREATE UNIQUE INDEX indexName ONmytable(username(length)) ◆修改表結構
ALTER mytable ADD UNIQUE [indexName] ON(username(length)) ◆創建表的時候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );
（3）主鍵索引
它是一種特殊的唯一索引，不允許有空值。一般是在建表的時候同時創建主鍵索引：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) ); 當然也可以用 ALTER 命令。記住：一個表只能有一個主鍵。
（4）組合索引
為了形象地對比單列索引和組合索引，為表添加多個欄位：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL ); 為了進一步榨取MySQL的效率，就要考慮建立組合索引。就是將 name, city, age建到一個索引里：
ALTER TABLE mytable ADD INDEX name_city_age(name(10),city,age); 建表時，usernname長度為 16，這里用 10。這是因為一般情況下名字的長度不會超過10，這樣會加速索引查詢速度，還會減少索引文件的大小，提高INSERT的更新速度。
2. DB2資料庫更新數據緩慢，求優化建議
你這樣寫很不好，看起來寫的是一句sql，反而速度慢下來了。首先row_number() over() as rownum毫無必要，這樣來分頁效率不高。然後能不用*就不用*查詢。在大數據量和列很多的情況下，會慢很多。
而且你也說了，更新1W條數據需要半個小時。那麼可以採用存儲過程或者程序來訪問。這樣會快很多，推薦採用存儲過程，110W條數據，就算重建索引等，更新一條應該在200ms一下，一萬條，不會那麼久的。希望能幫助得到你。
你這樣寫sql語句，執行時間太久了，會造成假死現象，這樣很不好。
3. 資料庫插入數據或更新數據的時候反應很慢，怎麼優化
查詢速度慢，跟你的插入沒多大關系
大表sdy_db_testb的C_testa欄位建索引；
把select a.*,b.c_xname from sdy_db_testb a left join sdy_db_testc b on 1=1 and b.c_testa=a.c_testa改成
select a.*,b.c_xname from sdy_db_testc a left join sdy_db_testb b on 1=1 and b.c_testa=a.c_testa;
即左邊的為小表，這樣就快 了；
不知道你的需求是否要把大表的數據都取出來
如果是都需要取出來的話，慢是必然的！因為要讀的塊數無法減少，IO開銷你怎麼優化都是無用的
4. 用PB開發的一個資料庫伺服器多個異地客戶端使用查詢更新速度慢問題解決的技術方法
處理的方法很簡單：
1、並不是所有的地方都需要使用read commit的加鎖級別，你從application中設置一句sqlca.lock="RU", 使用臟讀，這樣就可以去掉大多數不必要的SELECT行鎖。然後在一定要讀最新數據的地方，把SQLCA。LOCK改為RC，用完後再改回來。
這樣就避免了幾乎80%的阻塞。
2、對於由於行更新，或者其他UPDATE導致的鎖，一般資料庫會自己協調，在事務比較長的情況下，這需要你對原來的程序做適當的修改。把長事務變為幾個小的事務，在事務中做更新操作，不要插入用戶的交互。這是系統的設計原則。
如果你的系統對事務的要求不嚴格，又不想改動原來的程序，辦法更簡單，在前面
SQLCA。LOCK的基礎上，加句SQLCA。AUTOCOMMIT=TRUE，這樣每數據修改自動提交，就可以避免大多數由於更新產生的死鎖和阻塞。
3、最後要對付的是剛才說的被大量應用頻繁訪問的表（HOT TABLE），如果你的系統允許使用RU加鎖級別，那麼不用太考慮，因為SELECT已經不會導致鎖定了。
但是如果你不能使用RU方式（1里頭提到的辦法），
那麼要採用這樣的手段：
使用索引把更新鎖，SELECT鎖來分開，同時也避免SQLSERVER傻傻為了性能的原因把行鎖升級為表鎖。
具體辦法是建立一個索引，如果可以的話使用聚集索引，因為聚集索引採用的是類似HASH的檢索方式，這樣當查找索引的時候，就不需要訪問數據表了。
另一種辦法，是將你SELECT語句中要檢索的數據都加到索引中，例如你檢索NAME，SEX，AGE，如果你把三個數據都加入了索引，這就意味著SELECT語句只要找到索引，就已經找到了最後要選取的數據（從索引中），這樣自然不會去LOCK表了。這樣做的時候要針對你的程序仔細選擇索引，否則把索引變成了表的一個備份就沒有意義了。
5. 資料庫大量數據update慢，如何克服
用的是單機資料庫嗎？ 如果數據量過大性能可能無法支撐，可以嘗試改用分布式資料庫。
相對於單機資料庫，分布式資料庫的數據分布式存儲，讀寫分離，性能高，在線一鍵平滑擴容，感興趣可以了解一下。
順便給個福利，華為雲分布式資料庫中間件DDM正在做試用體驗活動，可以了解一下。
6. 怎麼樣解決資料庫中的數據量比較大時訪問慢的問題
數據量比較大的訪問速度慢問題，就目前來說，我遇到的解決方法有一些，首先盡量不使用select *，因為資料庫在進行查詢時會把*對應的列進行解析，會使得資料庫的訪問速度變慢，查詢時應該選擇需要的列；另外在查詢時需要在關鍵列上建立索引，索引是提高訪問資料庫速度的最重要的手段，一般訪問速度慢的問題中，90%可以使用建立索引來解決，具體怎麼建立索引還請樓主自己查看相關資料；再一個就是及時對表進行數據分析，分析過的表能夠自己選擇合適的索引，使得查詢性能在一定程度上得到提高（但是資料庫自己選擇的執行路徑也不一定都是正確的，這一點需要具體問題具體分析）。
7. 如何解決mysql 查詢和更新速度慢
問題
我們有一個 SQL，用於找到沒有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎麼辦?
實驗
我們搭建一個 MySQL 5.7 的環境，此處省略搭建步驟。
寫個簡單的腳本，製造一批帶主鍵和不帶主鍵的表：
可以看到執行時間變成了 0.67s。
整理
我們診斷的關鍵點如下：
1. 對於 information_schema 中的元數據表，執行計劃不能提供有效信息。
2. 通過查看 MySQL 改寫後的 SQL，我們猜測了優化器發生了誤判。
3. 我們增加了 hint，指導 MySQL 正確進行優化判斷。
但目前我們的實驗僅限於猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
8. MySQL資料庫伺服器逐漸變慢分析與解決方法分享
一、檢查系統的狀態
通過操作系統的一些工具檢查系統的狀態，比如CPU、內存、交換、磁碟的利用率，根據經驗或與系統正常時的狀態相比對，有時系統表面上看起來看空閑，這也可能不是一個正常的狀態，因為cpu可能正等待IO的完成。除此之外，還應觀注那些佔用系統資源(cpu、內存)的進程。
1.使用sar來檢查操作系統是否存在IO問題
#sar-u210—
即每隔2秒檢察一次，共執行20次。
結果示例：
註：在redhat下，%system就是所謂的%wio。
Linux2.4.21-20.ELsmp
(YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
其中：
%usr指的是用戶進程使用的cpu資源的百分比;
%sys指的是系統資源使用cpu資源的百分比;
%wio指的是等待io完成的百分比，這是值得觀注的一項;
%idle即空閑的百分比。
如果wio列的值很大，如在35%以上，說明系統的IO存在瓶頸，CPU花費了很大的時間去等待I/O的完成。Idle很小說明系統CPU很忙。像以上的示例，可以看到wio平均值為11，說明I/O沒什麼特別的問題，而idle值為零，說明cpu已經滿負荷運行了。
2.使用vmstat監控內存
cpu資源
[root@mysql1
~]#
vmstat
procs
———–memory———-—swap–
—–io—-–system–
—–cpu——
r
b
swpd
free
buff
cache
si
so
bi
bo
in
cs
us
sy
id
wa
st
0
0
72
25428
54712672264
0
0
14
43
53
59
1
198
0
0
vmstat
的輸出那些信息值得關注?
io
bo:
磁碟寫的數據量稍大，如果是大文件的寫，10M以內基本不用擔心，如果是小文件寫2M以內基本正常
①
CPU問題
下面幾列需要被察看，以確定cpu是否有問題
Processesinthe
run
queue
(procs
r)
Usertime
(cpu
us)
System
time
(cpu
sy)
Idle
time
(cpu
id)
問題情況:
如果processes
in
run
queue
(procs
r)的數量遠大於系統中cpu的數量，將會使系統便慢。
如果這個數量是cpu的4倍的話，說明系統正面臨cpu能力短缺,這將使系統運行速度大幅度降低
如果cpu的idle時間經常為0的話，或者系統佔用時間(cpu
sy)是用戶佔用時間(cpu
us)兩輩的話，系統面臨缺少cpu資源
解決方案
:
解決這些情況，涉及到調整應用程序，使其能更有效的使用cpu，同時增加cpu的能力或數量
②內存問題
主要查看頁導入的數值(swap中的si)，如果該值比較大就要考慮內存，大概方法如下：
最簡單的，加大RAM
減少RAM的需求
3.磁碟IO問題
處理方式：做raid10提高性能
4.網路問題
telnet一下MySQL對外開放的埠，如果不通的話，看看防火牆是否正確設置了。另外，看看MySQL是不是開啟了skip-networking的選項，如果開啟請關閉。