數據庫構建有什麼經驗？
1.標準的對象命名規範
2.設計數據庫的時候滿足3大範式
- 第一範式（1NF）：原子性，數據不可再分：一個表中的數據（字段值）不可再分
- 唯一性，消除部分依賴：一個表中的每一行必須唯一可區分，且非主鍵字段值完全依賴主鍵字段值。
- 獨立性，消除傳遞依賴，使一個表中的任何一個非主鍵，完全獨立地依賴於主鍵，而不能又依賴於另外的非主鍵。
儘可能的減少數據冗餘
3 .將經常需要操作的數據和不經常操作的數據分開
4.仔細的選擇數據類型。
char 自動補齊後面空格，最大255個字符
varchar可變字符串 最大65532個字節 取決於最大行存儲量 另外需要1-2字節長度標識（每個變長字段額外使用1或者2個字節記錄實際數據長度），NULL標識位（是否爲NULL）;
5.創建適當的索引
- 避免非必要索引，因爲表設置索引要付出代價的：一是增加了數據庫的存儲空間，二是在插入和修改數據時要花費較多的時間(因爲索引也要隨之變動)。
- 索引所用到的數據結構，B樹及其B+樹，運用二叉查找在O(log2n)的複雜度內獲取到相應數據。
- 經常使用索引的列： 經常搜索的列上，加快搜索速度 。 主鍵列上，強制該列唯一性和數據的排列結構。 外鍵上加快連接。經常排序的列上，和where子句中的列上。
聚集索引
6.OPTIMIZE TABLE
MVC的優點
低耦合性
高重用性和可適用性
可維護性好
較低的生命週期成本
快速的部署
有利於軟件工程化管理
當然優點也有缺點，那就是內部結構複雜，不容易理解，文件數量大，管理難度自然也就大
三層架構和MVC區別
三層是從整個應用程序架構的角度來分的三層（如果程序需要，還可以分多層）。
三層是爲了解決整個應用程序中各個業務操作過程中不同階段的代碼封裝的問題，爲了使程序員更加專注的處理某階段的業務邏輯。
MVC是在應用程序（BS結構）的視圖層劃分出來的不同功能的幾個模塊。
MVC主要是爲了解決應用程序用戶界面的樣式替換問題，把展示數據的 HTML 頁面儘可能的和業務代碼分離。
MyISAM和InnoDB的區別
1.MySQL5.5版本之後默認採用的是Innodb引擎。
2.MyISAM不支持事務，而InnoDB支持。InnoDB的AUTOCOMMIT默認是打開的，即每條SQL語句會默認被封裝成一個事務，自動提交，這樣會影響速度，所以最好是把多條SQL語句顯示放在begin和commit之間，組成一個事務去提交。
3.InnoDB支持數據行鎖定，MyISAM不支持行鎖定，只支持鎖定整個表。即MyISAM同一個表上的讀鎖和寫鎖是互斥的，MyISAM併發讀寫時如果等待隊列中既有讀請求又有寫請求，默認寫請求的優先級高，即使讀請求先到，所以MyISAM不適合於有大量查詢和修改並存的情況，那樣查詢進程會長時間阻塞。因爲MyISAM是鎖表，所以某項讀操作比較耗時會使其他寫進程餓死。
4.InnoDB支持外鍵，MyISAM不支持。
5.InnoDB的主鍵範圍更大，最大是MyISAM的2倍。
6.InnoDB不支持全文索引，而MyISAM支持。全文索引是指對char、varchar和text中的每個詞（停用詞除外）建立倒排序索引。MyISAM的全文索引其實沒啥用，因爲它不支持中文分詞，必須由使用者分詞後加入空格再寫到數據表裏，而且少於4個漢字的詞會和停用詞一樣被忽略掉。
7.沒有where的count()使用MyISAM要比InnoDB快得多。因爲MyISAM內置了一個計數器，count()時它直接從計數器中讀，而InnoDB必須掃描全表。所以在InnoDB上執行count()時一般要伴隨where，且where中要包含主鍵以外的索引列。爲什麼這裏特別強調“主鍵以外”？因爲InnoDB中primary index是和raw data存放在一起的，而secondary index則是單獨存放，然後有個指針指向primary key。所以只是count()的話使用secondary index掃描更快，而primary key則主要在掃描索引同時要返回raw data時的作用較大。
值得注意的5.0版本以上，varchar(50)，指的是50字符，無論存放的是數字、字母還是UTF8漢字（每個漢字3字節），都可以存放50個
4.0版本以下，varchar(50)，指的是50字節，如果存放UTF8漢字時，只能存16個（每個漢字3字節）
Mysql char and varchar
VARCHAR與CHAR兩種字符型數據類型相比，最大的差異就是前者是可變長度，而後者則是固定長度。在存儲時，前者會根據實際存儲的數據 來分配最終的存儲空間。而後者則不管實際存儲數據的長度，都是根據CHAR規定的長度來分配存儲空間。雖然VARCHAR數據類型可以節省存儲空間，提高數據處理的效率。但是其可變長度帶來的一 些負面效應
可變長度的字符數據類型，其存儲的長度是可變的。當其更改前後數據長度不一致時，就不可避免的會出現碎片的問題。故使用可變長度的字符 型數據時，數據庫管理員要時不時的對碎片進行整理。如執行數據庫導出導入作業，來消除碎片。
對於VARCHAR數據類型來說，硬盤上的存儲空間雖然都是根據實際字符長度來分配存儲空間的，但是對於內存來 說，則不是。其時使用固定大小的內存塊來保存值，這對於排序或者臨時表操作（這些內容都 需要通過內存來實現）作業會產生比較大的不利影響，採用varchar定義長度。
所以在使用長度基本相同，長度在255字節以內的建議使用char類型
ThinkPHP
自動驗證：$_validate
前端模板：ThinkTemplate
自動備份：crontab 分 時 日 月 周 command
數據庫優化
目的
- 數據庫連接timeout產生5xx錯誤
- 慢查詢造成頁面無法加載
- 阻塞造成數據無法提交
目的減少數據庫低效查詢
優化方向
mysql數據庫是基於文件的
SQL及索引：結構良好的SQL以及有效的索引，如果索引過多會對數據插入以及讀取是有影響的
數據庫表結構：一個好的數據庫表結構
系統配置：TCP/IP最大連接數，打開文件數的限制
硬件：內存方面，更快IO設備（SSD），但是並不能防止數據庫鎖的限制，減少阻塞，cpu方面需求不是很大
SQL及索引
慢查詢日誌
方式：mysqldumpslow
pt-query-digest
通過慢查詢日誌發現有問題的SQL？
1.查詢次數多且每次查詢佔用時間長的SQL
pt-query-digest分析的前幾個查詢
2.
IO大的SQL，掃描行數多的
3.
爲命中索引的SQL
分析SQL查詢
使用explain查詢SQL的執行計劃
type 顯示連接使用了何種類型 最好到最差爲 const,eq_reg，ref，range（索引範圍），index（索引掃描），all
extra : Using filesort 對返回的所有行進行額外排序
Using temporary 會創建一個臨時表
sql語句優化：
max（） 全表掃描 一定加索引
count（加or null）
將子查詢優化成連接查詢 但是要將distinct 對連接查詢去重
group by 分組連接查詢 先將連接再查詢，不要查詢後再連接
order by 全表掃描 一定要加索引
Limit 分頁時 記錄上次返回的行數，加上where判斷語句，來減少掃描的行數
索引優化
在group by 從句 ，order by 從句，on，where中加索引
對錶的數據全部加上索引叫做覆蓋索引，一般在字段比較少的時候
索引字段越小越好 存儲是按頁存儲，減少IO。
離散度大的放在聯合索引的前面
不得不說增加索引會加快查詢速度，但會減少寫入速度
如果索引過多系統還需要去判斷需要用哪一個索引
innodb會在每一個索引後都加上主鍵索引
pt-duplicate-key-checker工具檢查重複及冗餘索引
pt-index-usage 刪除不用的索引
Memcache 和 Redis
共同點：都是將數據緩存在內存中
不同點：Redis有部分存在硬盤上，這樣能保證數據的持久性
並當(物理內存用完時)可以將數據存向外存
Memcache 只支持key/value存儲
Redis 還支持list ，set，hash等存儲結構
Redis中通過set get del setex（設置過期時間操作） 默認端口號 6379
Memcache 默認端口號 11211
MongoDB
MongoDB基於文件的非關係型數據庫，雖然被是一款非關係數據庫，但其當很像關係數據庫的。他支持的數據結構是類似於json的bson格式，可以存y儲數據結構非常鬆散。查詢語句很強大，還支持對數據建立索引。
PHP垃圾回收機制
我們的代碼中用了unset,null,mysql_close,__destruct等等一些函數去釋放對象防止內存溢出，
PHP自身使用了引用計數(reference counting)這種單純的垃圾回收(garbage collection)機制。每個對象都內含一個引用計數器，每個引用連接到對象，計數器加1。當引用離開生存空間或被設爲NULL，計數器減1。當某個對象的引用計數器爲零時，PHP知道你將不再需要使用這個對象，釋放其所佔的內存空間。
如何處理PHP高併發問題
- //高性能服務器，能夠支持維度的訪問量
- 構建分佈式服務器，並且儘量的能夠做到負載均衡
- 優化數據庫訪問，儘量使前臺實現頁面靜態化。但經常更新的網站，將動態數據緩存到文件中，由服務器直接去訪問文件，或者加一層Redis數據庫或者memcached緩存，將數據緩存在內存中
- //如果要用到數據庫訪問的話，優化其SQL語句，增加索引命中率。利用存儲過程緩存執行計劃
- 禁止外部的盜鏈。 （外部盜鏈將會對服務器造成巨大壓力）
- 控制文件的下載，文件的下載會對服務器消耗巨大的流量並且消耗CPU，控制文件大小，如果可能單獨做一臺文件傳輸服務器
- 消息隊列（加在第二條後面）
- server。使用nginx+fpm或者nginx+apache，來實現動靜態分離訪問。（第三條裏說）
簡單的說就是
1. 讓同時併發數量降下來
2. 讓同時處理效率升上去
能靜態化的靜態化
不能靜態化的用分佈式算法
PHP函數
preg_match() 字符串正則匹配
date()
strtotime()將時間轉爲時間戳