推薦：30種mysql優化sql語句查詢的方法
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。 2.應盡量避免在 where 子句中使用!=或操作符，否則將引擎放棄使用索引而進行全表掃描。 3.應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引

　　如果你已經熟悉技術，那么基本上你已經沒什么問題了。精通的人在一天之內就可以把 MySQL 學會，把這個經驗加到他的履歷表里面去。相較之下，Access 是個復雜得多的及開發工具。即使是一個能力不錯的開發工程師也需要一段時間才能具備足夠的專業知識，有效地使用這個軟件。

　　正如你期待的，MySQL 支持結構化查詢語言(Structured Query Language ,SQL)。如果你已經學會某種版本的 SQL 語言，事情會好辦很多。具有 VB 或者是 VBA 知識背景的開發工程師會發現，他們以前所具備的 ASP 背景，能夠幫助他們縮短學習時間。

　　▲客戶支持

　　雖然好用而且免費的客戶支持已不存在，然而MySQL 倒提供了一些電子群組名單供您參考。有一些是頗具技術性的，而且會員們往往互相提供最佳的客戶支持 -- 他們彼此分享經驗和專業知識。此外，你還可以購買具有 客戶支持 的版本，包括 email 支持或者電話支持的方式。大致上來說，客戶支持費率并非固定的，因此我們無法提供你相關價位的信息。

　　▲MySQL 的不足之處

　　Access 是一個關聯性管理系統(RDBMS)，然而 MySQL 并非在每一個層面都是如此。這表示，雖然 MySQL 很好用，它還不是最好的。 以下列表記錄了目前關聯性層面以及管理層面，MySQL 尚未支持的部分:

　　MySQL 沒法處理復雜的關聯性功能，例如，子查詢(subqueries)，雖然大多數的子查詢都可以改寫成 join。我們期待下一版出來時，這項功能會被加進來。

　　另一個 MySQL 沒有提供支持的功能是事務處理(transaction)以及事務的提交(commit)/撤銷(rollback)。 一個事務指的是被當作一個單位來共同執行的一群或一套命令。如果一個事務沒法完成，那么整個事務里面沒有一個指令是真正執行下去的。對于必須處理線上訂單的商業網站來說， MySQL 沒有支持這項功能，的確讓人覺得很失望。 但是可以用MaxSQL，一個分開的，它能通過外掛的表格來支持事務功能。

　　外鍵(foreign key)以及參考完整性限制(referential integrity)可以讓你制定表格中資料間的約束，然後將約束(constraint)加到你所規定的資料里面。這些MYSQL沒有的功能表示一個有賴復雜的資料關系的應用程序并不適合使用 MySQL。 當我們說 MySQL 不支持外鍵時，我們指的就是的參考完整性限制 -- MySQL 并沒有支持外鍵的規則，當然更沒有支持連鎖刪除(cascading delete)的功能。 簡短的說，如果你的工作需要使用復雜的資料關聯，那你還是用原來的 Access 吧。

　　你在 MySQL 中也不會找到存儲進程(stored procedure)以及觸發器(trigger)。(針對這些功能，在 Access 提供了相對的事件進程(event procedure)。)

　　Access 的 GetRows 功能，提供了較好的資料拾取。

　　▲總結

　　下面這個表格能讓你對于 MySQL，Access，以及 SQL Server 大致上比起來是怎么樣有個基本概念:

　　□訪問頻繁的網站

　　·MySQL √

　　·Access √**

　　·SQL Server √

　　□復雜的資料關聯

　　·MySQL ×

　　·Access √

　　·SQL Server √

　　□在線訂單處理

　　·MySQL √*

　　·Access √***

　　·SQL Server √

　　□兼容性

　　·MySQL ×

　　·Access √****

　　·SQL Server √

　　□易于使用及操作

　　·MySQL √

　　·Access ×

　　·SQL Server ×

　　注：

　　* 需要MaxSQL

　　** 前提是資料只讀的話

　　*** 通過Jet SQL獲得的附加功能

　　**** 因為只有ADO

　　如果你需要使用復雜的，并且有很多資源和金錢，那么你就用 SQL Server 吧。如果你仍舊需要復雜的但是卻沒有雄厚的後援，那么用 Access 看看。至于其他的人，至少應該給 MySQL 一個使用的機會吧!

分享：mysql 定時更新表字段列的值狀態
現在又兩個表tcm,doc; db_count: id count 1 220 2 300 3 220 4 222 5 240 db_date: id t_date count 1 2012-09-10 17:04:07 220 2 2012-09-11 15:04:07 224 3 2012-08-20 11:04:07 225 4 2012-02-11 17:04:07 300 5 2012-09-11 10:04:07 500 6 2012-09-12 17:04:07 30