1.資料庫

資料刪除 delete drop truncate

索引過多會導致查詢速度過慢 ,降低效能。因為太多的索引與不充分、不正確的索引對效能都毫無益處：在表上建立的每個索引都會增加儲存開銷，索引對於插入、刪除、更新操作也會增加處理上的開銷。另外，過多的複合索引，在有單欄位索引的情況下，一般都是沒有存在價值的；相反，還會降低資料增加刪除時的效能，特別是對頻繁更新的表來說，負面影響更大。

group by 是分組的，和having

WHERE過濾行，HAVING過濾組

   例如，查詢僱員平均工資大於3000的部門的最高薪水和最低薪水:

1. SELECT dept,MAX(salary) AS MAXIMUM,MIN(salary) AS MINIMUM

2. FROM STAFF

3. GROUP BY dept

4. HAVING AVG(salary) > 3000

5. ORDER BY dept

查詢結果如下:

1. dept MAXIMUM MINIMUM

2. 銷售部 3500 3000

2.python

基本型別：

• Number（數字）
• String（字串）
• List（列表）
• Tuple（元組）
• Set（集合）
• Dictionary（字典）

number Python3 支援int、float、bool、complex（複數）。

list 列表可以完成大多數集合類的資料結構實現。列表中元素的型別可以不相同，它支援數字，字串甚至可以包含列表（所謂巢狀）。

列表是寫在方括號[]之間、用逗號分隔開的元素列表。

和字串一樣，列表同樣可以被索引和擷取，列表被擷取後返回一個包含所需元素的新列表。

3.資料結構

陣列、連結串列

陣列和連結串列都是線性表的結構，只不過它們的儲存方式不一樣；
根據儲存方式不同，可將線性表分為順序表和鏈式表；
線性表是資料結構中的邏輯結構。可以儲存在陣列上，也可以儲存在連結串列上。
一句話，用陣列來儲存的線性表就是順序表。

陣列：在記憶體中，是一塊連續的記憶體區域；
連結串列：是由不連續的記憶體空間組成；

陣列優點：隨機訪問性強，查詢速度快（連續記憶體空間導致的）；
陣列缺點：插入和刪除效率低可能浪費記憶體記憶體空間要求高，必須有足夠的連續記憶體空間。陣列大小固定，不能動態拓展

連結串列的優點：插入刪除速度快 記憶體利用率高，不會浪費記憶體大小沒有固定，拓展很靈活。（每一個數據儲存了下一個資料的地址，增刪效率高）
連結串列的缺點：不能隨機查詢，必須從第一個開始遍歷，查詢效率低

4.網路

get 和post區別：

1. get從服務端請求資料，post傳遞
2. 傳遞的大小有區別。get 有限的大小2kb，post不限大小
3. url requestely
4. 場景不一樣。文字 文字和二進位制
5. get傳送的資料是url的一部分，不安全。post比較安全，因為引數不儲存在瀏覽器歷史和web伺服器日誌

head options delete put

1、GET請求會向資料庫發索取資料的請求，從而來獲取資訊，該請求就像資料庫的select操作一樣，只是用來查詢一下資料，不會修改、增加資料，不會影響資源的內容，即該請求不會產生副作用。無論進行多少次操作，結果都是一樣的。

2、PUT請求是向伺服器端傳送資料的（與GET不同）從而改變資訊，該請求就像資料庫的update操作一樣，用來修改資料的內容，但是不會增加資料的種類等，也就是說無論進行多少次PUT操作，其結果並沒有不同。

3、POST請求同PUT請求類似，都是向伺服器端傳送資料的，但是該請求會改變資料的種類等資源，就像資料庫的insert操作一樣，會建立新的內容。幾乎目前所有的提交操作都是用POST請求的。

4、DELETE請求顧名思義，就是用來刪除某一個資源的，該請求就像資料庫的delete操作。

就像前面所講的一樣，既然PUT和POST操作都是向伺服器端傳送資料的，那麼兩者有什麼區別呢。。。POST主要作用在一個集合資源之上的（url），而PUT主要作用在一個具體資源之上的（url/xxx），通俗一下講就是，如URL可以在客戶端確定，那麼可使用PUT，否則用POST

1，GET：GET可以說是最常見的了，它本質就是傳送一個請求來取得伺服器上的某一資源。資源通過一組HTTP頭和呈現據（如HTML文字，或者圖片或者視訊等）返回給客戶端。 GET請求中，永遠不會包含呈現資料。 2，HEAD：HEAD和GET本質是一樣的，區別在於HEAD不含有呈現資料，而僅僅是HTTP頭資訊。有的人可能覺得這個方法沒什麼用，其實不是這樣的。 想象一個業務情景：欲判斷某個資源是否存在，我們通常使用GET，但這裡用HEAD則意義更加明確。 3，PUT：這個方法比較少見。HTML表單也不支援這個。本質上來講， PUT和POST極為相似，都是向伺服器傳送資料，但它們之間有一個重要區別， PUT通常指定了資源的存放位置，而POST則沒有，POST的資料存放位置由伺服器自己決定。舉個例子：如一個用於提交博文的URL，/addNew。 如果用PUT，則提交的URL會是像這樣的”/addNew/abc123”，其中abc123就是這個博文的地址。而如果用POST，則這個地址會在提交後由伺服器告知客戶端。 目前大部分部落格都是這樣的。顯然，PUT和POST用途是不一樣的。具體用哪個還取決於當前的業務場景。 4，DELETE：刪除某一個資源。基本上這個也很少見，不過還是有一些地方比如amazon的S3雲服務裡面就用的這個方法來刪除資源。 5，POST：向伺服器提交資料。這個方法用途廣泛，幾乎目前所有的提交操作都是靠這個完成。 6，OPTIONS：這個方法很有趣，但極少使用。它用於獲取當前URL所支援的方法。若請求成功，則它會在HTTP頭中包含一個名為“Allow”的頭，值是所支援的方法，如“GET, POST”。

1、POST    /url      建立
2、DELETE  /url/xxx  刪除  
3、PUT     /url/xxx  更新
4、GET     /url/xxx  檢視

TCP 長連結 短連結

長連線：

所謂長連線，指在一個TCP連線上可以連續傳送多個數據包，在TCP連線保持期間，如果沒有資料包傳送，需要雙方發檢測包以維持此連線，一般需要自己做線上維持（不發生RST包和四次揮手）。

連線→資料傳輸→保持連線(心跳)→資料傳輸→保持連線(心跳)→……→關閉連線（一個TCP連線通道多個讀寫通訊）；
這就要求長連線在沒有資料通訊時，定時傳送資料包(心跳)，以維持連線狀態；

TCP保活功能，保活功能主要為伺服器應用提供，伺服器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得伺服器上保留一個半開放的連線，而伺服器又在等待來自客戶端的資料，則伺服器將應遠等待客戶端的資料，保活功能就是試圖在伺服器端檢測到這種半開放的連線。

如果一個給定的連線在兩小時內沒有任何的動作，則伺服器就向客戶發一個探測報文段，客戶主機必須處於以下4個狀態之一：

1. 客戶主機依然正常執行，並從伺服器可達。客戶的TCP響應正常，而伺服器也知道對方是正常的，伺服器在兩小時後將保活定時器復位。
2. 客戶主機已經崩潰，並且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，並在75秒後超時。伺服器總共傳送10個這樣的探測 ，每個間隔75秒。如果伺服器沒有收到一個響應，它就認為客戶主機已經關閉並終止連線。
3. 客戶主機崩潰並已經重新啟動。伺服器將收到一個對其保活探測的響應，這個響應是一個復位，使得伺服器終止這個連線。
4. 客戶機正常執行，但是伺服器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。

短連線：

短連線是指通訊雙方有資料互動時，就建立一個TCP連線，資料傳送完成後，則斷開此TCP連線（管理起來比較簡單，存在的連線都是有用的連線，不需要額外的控制手段）；

連線→資料傳輸→關閉連線；

應用場景：

長連線多用於操作頻繁（讀寫），點對點的通訊，而且連線數不能太多情況，。每個TCP連線都需要三步握手，這需要時間，如果每個操作都是先連線，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接傳送資料包就OK了，不用建立TCP連線。例如：資料庫的連線用長連線， 如果用短連線頻繁的通訊會造成socket錯誤，而且頻繁的socket 建立也是對資源的浪費。

而像WEB網站的http服務一般都用短連結（http1.0只支援短連線，1.1keep alive 帶時間，操作次數限制的長連線），因為長連線對於服務端來說會耗費一定的資源，而像WEB網站這麼頻繁的成千上萬甚至上億客戶端的連線用短連線會更省一些資源，如果用長連線，而且同時有成千上萬的使用者，如果每個使用者都佔用一個連線的話，那可想而知吧。所以併發量大，但每個使用者無需頻繁操作情況下需用短連好；

在長連線中一般是沒有條件能夠判斷讀寫什麼時候結束，所以必須要加長度報文頭。讀函式先是讀取報文頭的長度，再根據這個長度去讀相應長度的報文。

5.lunix

檢視日誌：tail

6.前臺

cookie section

Cookie是伺服器在本地機器上儲存的小段文字並隨每一個請求傳送至同一伺服器。Cookies儲存在客戶端，主要內容包括：名字，值，過期時間，路徑等等。

Session是在伺服器端儲存使用者資料。瀏覽器第一次傳送請求時，伺服器自動生成了Session ID來唯一標識這個並將其通過響應傳送到瀏覽器。瀏覽器第二次傳送請求會將前一次伺服器響應中的Session ID放在請求中一併傳送到伺服器上，伺服器從請求中提取出Session ID，並和儲存的所有Session ID進行對比，找到這個使用者的資訊。一般這個Session ID會有個時間限制，預設30分鐘超時後毀掉這次Session ID。

Session和Cookie有一定關係，Session id存在Cookie中，每次訪問的時候將Session id傳到伺服器進行對比。

(1)cookie資料存放在客戶的瀏覽器上，session資料放在伺服器上
(2)cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙,如果主要考慮到安全應當使用session
(3)session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能，如果主要考慮到減輕伺服器效能方面，應當使用COOKIE
(4)單個cookie在客戶端的限制是3K，就是說一個站點在客戶端存放的COOKIE不能3K。
(5)所以：將登陸資訊等重要資訊存放為SESSION;其他資訊如果需要保留，可以放在COOKIE中

1. Cookie 在客戶端（瀏覽器、易偽造、不安全），Session 在伺服器端（會消耗伺服器資源）。
2. Cookie 只能儲存ASCII字串，如果是Unicode字元或者二進位制資料需要先進行編碼。Cookie中也不能直接存取Java物件。 Session能夠存取很多型別的資料，包括String、Integer、List、Map等，Session中也可以儲存JJava物件。

7.作業系統

指令分類