主要是指三方面，即表結構、字段結構以及索引結構，這些結構如果不合理，在某些場景下也會影響數據庫的性能，因此優化時也可以從結構層面出發。一般在項目的庫表設計之初就要考慮，當性能瓶頸出現時再調整結構，就為時過晚。

1. 表結構的優化

表結構設計時字段數量一定不要太多，InnoDB引擎基本上都會將數據操作放到內存中完成，一張表的字段數量越多，能載入內存的數據頁會越少，當操作時數據不在內存，又不得不去磁盤中讀取數據，這顯然會很大程度上影響MySQL性能。

表結構的設計，正常情況下應當遵循《數據庫三范式》的原則設計，盡可能的根據業務將表結構拆分的更為精細化，一方面確保內存中緩存的數據更多，更便于維護，而且執行SQL時，效率也會越高。

主鍵選擇要合適，一張表中必須要有主鍵且最好是順序遞增的。一張表如果業務中自帶自增屬性字段，最好選擇這些字段作為主鍵。沒有可以設計一個與業務無關、無意義的數值序列。

對實時性要求不高的數據建立中間表。很多時候為了統計一些數據時，都會基于多表做聯查，以此來確保得到統計所需的數據，對于實時性的要求不高，可以在庫中建立相應的中間表，然后每日定期更新中間表的數據，從而減小聯表查詢的開銷，同時也能進一步提升查詢速度。

根據業務特性為不同的表選擇合適的存儲引擎，主要在InnoDB、MyISAM之間做選擇。經常查詢，很少發生變更的表可以選擇MyISAM引擎。其他表可以使用默認的InnoDB引擎。

2. 字段結構的優化

設計表時選擇合適的數據類型

• 姓名字段，一般都會限制用戶名長度，不要無腦用varchar，使用char類型更好。
• 一些顯然不會擁有太多數據的表，主鍵ID的類型可以從int換成tinyint、smallint、mediumit。
• 日期字段，不要使用字符串類型，更應該選擇datetime、timestamp，一般情況下最好為后者。
• 一些固定值的字段，如性別、狀態、省份、國籍等字段，可以選擇使用數值型代替字符串，如果必須使用字符串類型，最好使用enum枚舉類型代替varchar類型。

總之保持三個原則：

1. 足夠的使用范圍內選擇最小的數據類型，它們占用更少的磁盤、內存、和CPU緩存，處理速度也會更快
2. 避免索引字段值為NULL，字段空值過多會影響索引性能
3. 盡量使用簡單的類型代替復雜的類型，如IP的存儲可以使用int而并非varchar，因為簡單的數據類型，操作時通常需要的CPU資源更少。

3. 索引結構的優化

根據業務創建更合適的索引，主要從4個方面考慮：

1. 一個表需要建立多個索引，適當根據業務將多個單列索引組合成一個聯合索引，可以節省磁盤空間，能夠充分使用索引覆蓋的方式查詢數據，一定程度上提升數據庫的整體性能。
2. 值較長的字段盡量建立前綴索引，索引字段值越小，單個B+Tree的節點中能存儲的索引鍵會越多，索引樹會越矮，查詢性能自然越高。
3. 經常做模糊查詢的字段，可以建立全文索引代替普通索引，基于普通索引做like查詢會導致索引失效，而采用全文索引的方式做模糊查詢效率會更高更快，并且全文索引的功能更為強大。
4. 索引結構的選擇根據業務進行調整，在某些不做范圍查詢的字段上建立索引時，可以選用hash結構代替B+Tree結構，Hash結構的索引是所有數據結構中最快的，散列度足夠的情況下，復雜度僅為O(1)。