❶ mysql優化一般需要做哪些其他資料庫優化也行（sql）

1.硬體層次的優化
高頻CPU，內存要大，磁碟轉速要快，網路帶寬要大。要硬體方面優化，花錢升級硬體吧。
2.軟體層次的優化
我大概寫一些吧，想到哪些寫哪些，希望對你有用。
（1）優化安裝mysql
一句話，只保留需要的、必須的，其他的統統丟掉。（這句話只適用於源碼編譯安裝的情況，如果不是，請跳過）比如，字元集。如果安裝全部字元集，大概有50多種吧...記不清了，大概有這么多，但是過多的字元集影響性能（雖然影響的不多，mysql查詢機制中有一步是字元集檢查）。源碼編譯安裝的話可以大量減少字元集，只保留必須的和自己需要的那些。我維護的一個mysql伺服器中的Mysql只有15個字元集。
還有就是配置文件、數據目錄、系統目錄不要放一塊。俗話說的好，雞蛋不要放在一個籃子里，不要在一顆樹上弔死...當然，這對性能沒有影響，考慮的是安全性。不是生產環境的，請無視這一條。
（2）內存分配優化。
在mysql中的配置文件中可以自定義多種緩存，適當的配給值可以提高mysql的整體性能。
比較重要的：
innodb_buffer_pool_size 這個值應該分配總內存的40-80%，總之 這個值越高越好。如果不是專屬mysql伺服器，那分配40%也很夠用了。
query_cache_size 這個值分配靈活性也比較大，從幾MB~幾百MB。它緩存查詢的結果集。查詢不是能頻繁、查詢數據不是很大量的情況，分配個幾MB就夠了，殺雞焉用牛刀啊，用內存的地方實在是多。
join_buffer_size，sort_buffer_size 一般設1MB，2MB就十分夠用了。這倆值千萬不要設置的太大，因為這倆緩存是分配給每個連接線程的，過多的連接線程可能導致內存不夠用。
tmp_table_size 同樣不是越大越好，分配10MB差不多夠用。以後有需要可以適當多分配點。臨時表緩存用於存放查詢時產生的臨時表，如果數據量大而tmp_table_size不夠用那麼Mysql會將臨時表存到磁碟上導致性能下降。個人經驗，當你覺得tmp_table_size不夠用的時候，不要隨便去增加這個值，而是檢查自己的SQL語句是否還可以優化。
（3）復制與讀寫分離
內容太多...這個不好寫啊。總之讀寫分離的目標是，安全、穩定、高效。訪問量少、只有一台電腦的請無視這一段...

mysql的優化知識全部寫出來能寫出一本磚頭厚的書，隨便寫了點自己知道的，能想到的。想了解更多，去看書吧。

我勒個去.....才看到題目後面的(sql)....吐一大口鮮血....你問的是sql優化？？？
再寫點個人經驗吧：
1.查詢時，能不用* 就不用，盡量寫全欄位名。
2.索引不是越多越好，每個表控制在6個索引以內。范圍where條件的情況下，索引不起作用，比如where value<100
3.大部分情況連接效率遠大於子查詢，但是有例外。當你對連接查詢的效率都感到不能接受的時候可以試試用子查詢，雖然大部分情況下你會更失望，但總有碰到驚喜的時候不是么...
4.多用explain 和 profile分析查詢語句
5.有時候可以1條大的SQL可以分成幾個小SQL順序執行，分了吧，速度會快很多。
6.每隔一段時間用alter table table_name engine=innodb;優化表
7.連接時注意:小表 jion 大表的原則
8.學會用explain 和 profile判斷是什麼原因使你的SQL慢。
9.查看慢查詢日誌，找出執行時間長的SQL試著優化去吧~~

以上。

❷ 在資料庫 如何實現多級樹啊 表結構要怎麼設置 比較好

無限級分類，很簡單。你可以下載動易的ACCESS資料庫，查看相應的表結構就知道是怎麼設計的了。

而且，它這個表設計的很巧妙，壓根就不需要遞歸循環，就能以樹形的結構列出所有的類別。僅僅需要order by rootid,orderid就可以了。

記得以前是用ASP開發的時候接觸到無限分類的，現在做PHP，.NET開發，都可以用它的那套機制。很好。

❸ 資料庫查詢有哪些優化方面

1 SQL查詢語句的重寫，對於一個查詢可以用多種查詢語句實現，但不同查詢語句的資料庫執行計劃是不同的，一旦不能夠使用索引或造成較大的內存佔用會導致性能下降，因此需要對查詢語句進行重寫優化，最典型的例子就是not in語句使用外連接方式實現來進行優化
2 創建合理的索引結構，根據查詢語句的中查詢條件，在關系表上建立相應的索引，如B+樹索引和hash索引
3 修改程序業務邏輯，有些功能如果使用SQL語句實現，不但SQL語句復雜，還將導致資料庫的負擔增加，因此可以將有些數據操作的業務邏輯放到應用層進行實現，就是通過java編程實現
4 修改資料庫伺服器相關參數，優化伺服器性能

❹ 怎樣用資料庫做成一個樹結構

就是表需要有一個主鍵，比如 ID
然後還有一個欄位，叫 父編號， 比如 PID
再加上其他的欄位，剩下的就是寫 SQL 的事情了。

例如下面這個表，就是一個可以做樹狀的。
CREATE TABLE test_tree (
test_id INT,
pid INT,
test_val VARCHAR(10),
PRIMARY KEY (test_id)
);

❺ 樹形結構數據的查詢怎麼優化

// 如果你指消息對話框，可以如下方法 QMessageBox msgBox; msgBox.setText("The document has been modified."); msgBox.exec();// 如果你指QDialog，那麼你只能在QDialog上面繪制你的界面，然後進行文字顯示QDialog *dlg = new QDialog();QLab...

❻ 資料庫語法樹問題

左邊優化前，右邊優化後

❼ 請問sql資料庫優化具體是指的哪些方面呢有沒有什麼工具軟體呢

1、資料庫邏輯設計的規范化 資料庫邏輯設計的規范化就是我們一般所說的範式，我們可以這樣來簡單理解範式：第1規范：沒有重復的組或多值的列，這是資料庫設計的最低要求。第2規范: 每個非關鍵欄位必須依賴於主關鍵字，不能依賴於一個組合式主關鍵字的某些組成部分。消除部分依賴，大部分情況下，資料庫設計都應該達到第二範式。第3規范: 一個非關鍵欄位不能依賴於另一個非關鍵欄位。消除傳遞依賴，達到第三範式應該是系統中大部分表的要求，除非一些特殊作用的表。更高的範式要求這里就不再作介紹了，個人認為，如果全部達到第二範式，大部分達到第三範式，系統會產生較少的列和較多的表，因而減少了數據冗餘，也利於性能的提高。2、合理的冗餘完全按照規范化設計的系統幾乎是不可能的，除非系統特別的小，在規范化設計後，有計劃地加入冗餘是必要的。冗餘可以是冗餘資料庫、冗餘表或者冗餘欄位，不同粒度的冗餘可以起到不同的作用。冗餘可以是為了編程方便而增加，也可以是為了性能的提高而增加。從性能角度來說，冗餘資料庫可以分散資料庫壓力，冗餘表可以分散數據量大的表的並發壓力，也可以加快特殊查詢的速度，冗餘欄位可以有效減少資料庫表的連接，提高效率。3、主鍵的設計主鍵是必要的，SQL SERVER的主鍵同時是一個唯一索引，而且在實際應用中，我們往往選擇最小的鍵組合作為主鍵，所以主鍵往往適合作為表的聚集索引。聚集索引對查詢的影響是比較大的，這個在下面索引的敘述。在有多個鍵的表，主鍵的選擇也比較重要，一般選擇總的長度小的鍵，小的鍵的比較速度快，同時小的鍵可以使主鍵的B樹結構的層次更少。主鍵的選擇還要注意組合主鍵的欄位次序，對於組合主鍵來說，不同的欄位次序的主鍵的性能差別可能會很大，一般應該選擇重復率低、單獨或者組合查詢可能性大的欄位放在前面。4、外鍵的設計外鍵作為資料庫對象，很多人認為麻煩而不用，實際上，外鍵在大部分情況下是很有用的，理由是：外鍵是最高效的一致性維護方法，資料庫的一致性要求，依次可以用外鍵、CHECK約束、規則約束、觸發器、客戶端程序，一般認為，離數據越近的方法效率越高。謹慎使用級聯刪除和級聯更新，級聯刪除和級聯更新作為SQL SERVER 2000當年的新功能，在2005作 了保留，應該有其可用之處。我這里說的謹慎，是因為級聯刪除和級聯更新有些突破了傳統的關於外鍵的定義，功能有點太過強大，使用前必須確定自己已經把握好 其功能范圍，否則，級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者丟失。從性能看級聯刪除和級聯更新是比其他方法更高效的方法。5、欄位的設計欄位是資料庫最基本的單位，其設計對性能的影響是很大的。需要注意如下：A、數據類型盡量用數字型，數字型的比較比字元型的快很多。B、數據類型盡量小，這里的盡量小是指在滿足可以預見的未來需求的前提下的。C、 盡量不要允許NULL，除非必要，可以用NOT NULL+DEFAULT代替。D、少用TEXT和IMAGE，二進制欄位的讀寫是比較慢的，而且，讀取的方法也不多，大部分情況下最好不用。E、自增欄位要慎用，不利於數據遷移。6、資料庫物理存儲和環境的設計在設計階段，可以對資料庫的物理存儲、操作系統環境、網路環境進行必要的設計，使得我們的系統在將來能適應比較多的用戶並發和比較大的數據量。這里需要注意文件組的作用，適用文件組可以有效把I/O操作分散到不同的物理硬碟，提高並發能力。7、系統設計整個系統的設計特別是系統結構設計對性能是有很大影響的，對於一般的OLTP系統，可以選擇C/S結構、三層的C/S結構等，不同的系統結構其性能的關鍵也有所不同。系統設計階段應該歸納一些業務邏輯放在資料庫編程實現，資料庫編程包括資料庫存儲過程、觸發器和函數。用資料庫編程實現業務邏輯的好處是減少網路流量並可更充分利用資料庫的預編譯和緩存功能。8、索引的設計在設計階段，可以根據功能和性能的需求進行初步的索引設計，這里需要根據預計的數據量和查詢來設計索引，可能與將來實際使用的時候會有所區別。關於索引的選擇，應改主意：A、根據數據量決定哪些表需要增加索引，數據量小的可以只有主鍵。B、根據使用頻率決定哪些欄位需要建立索引，選擇經常作為連接條件、篩選條件、聚合查詢、排序的欄位作為索引的候選欄位。C、把經常一起出現的欄位組合在一起，組成組合索引，組合索引的欄位順序與主鍵一樣，也需要把最常用的欄位放在前面，把重復率低的欄位放在前面。D、一個表不要加太多索引，因為索引影響插入和更新的速度。 具體有什麼工具，我就不知道了