shopex4.8.5是商派早年推出的一個基于php5.2平臺的半開源電子商務建站軟件，曾經一度有50多萬用戶使用。不過近年來更新比較少，加上有新的產品推出，官方對shopex的維護力度大不如前。很多用戶在使用中，發現并發到一定量時，網站訪問速度就明顯下降。由于shopex是并開源產品，只有專業的開發人員（手頭有源碼的）可以通過修改程序來優化程序性能。以下是幾個數據庫優化例子，是清風君在給用戶維護中的實戰經驗，成功將客戶的網站訪問速度由原來的數秒鐘提升到毫秒級。

優化實例1：payment_id字段類型錯誤導致的mysql查詢效率低

實例代碼：

select status from sdb_payments 
where payment_id=15519409588088 LIMIT 0, 1;

sdb_payments的payment_id雖然內容是數字，不過類型卻是varchar，這里沒有加單引號，會導致mysql轉類型，耗時太長。

解決辦法：

1）、修改程序，把payment_id加上單引號，

2）、能確定數據庫這個字段內容全部是數字的話，直接修改字段類型為TINYINT。

優化實例2：訂單表過大導致的查詢緩慢

實例代碼：

SELECT order_id FROM sdb_orders 
WHERE 1551978066>cancel_time 
AND pay_status='0' 
AND ship_status='0' 
AND status='active';

電商網站運營久了，最明顯的就是訂單表越來越大，導致查詢效率越來越低。

解決辦法：給訂單表增加pay_status、ship_status、status 索引

優化實例3：

實例代碼：

select * from sdb_orders where disabled="false" 
AND member_id=8356 
AND order_refer="local" 
AND isparent="false" order by createtime desc LIMIT 0, 20;

原因和實例2一樣。

解決辦法：

增加 member_id、disabled、order_refer、isparent 索引

優化實例4：

實例代碼：

SELECT queue_id,data,tmpl_name,target,title,event_name,sender,message
FROM sdb_msgqueue 
WHERE status='ready' 
OR (status='locking' AND send_time<1551940735 AND send_time>1551933655) 
ORDER BY level DESC LIMIT 0, 7;

由于shopex的站內消息不會自動清除，msgqueue表會越來越大，而每次客戶提交訂單時，又開啟了自動發送短信或郵件提醒功能，所以會觸發發送站內和郵件信息，導致提交訂單明顯卡頓。

解決辦法：

sdb_msgqueue 表增加status、send_time 索引。

以上是幾個優化實例，具體應該根據網站的運營數據和網站內容進行相應分析處理。如果有這方面的需求，歡迎與我們聯系。