java面試⑦進階部分

標籤：limit   外鏈   分享   不能   訊息   技巧   from   ble   sam   

2.6.1有沒有用過Linux？你都用它來做什嗎？

Linux是一個長時間運行比較穩定的作業系統，所以我們一般會拿他作為伺服器(web，db，app等)。

Linux本身具有C的編譯環境，我們的一些軟體是沒有軟體包的(redis等)，需要在Linux的C編譯環境編譯得到軟體包

2.6.2說一下Linux下面的一些常用命令

常用：

pwd 擷取當前路徑

cd 跳轉到目錄

su -u 切換到管理員

ls 列舉目錄

檔案操作命令：

檔案

tail 查看

rm -rf 刪除

vim 修改

檔案夾

mkdir 建立

rm -r 刪除

2.6.3你使用什麼來串連遠端Linux伺服器

串連遠程需要依賴於Linux伺服器安裝ssh服務端，一般這個ssh服務的連接埠為22

串連遠程需要依賴於Linux伺服器安裝sftp服務端，一般這個sftp服務的連接埠為25

使用ssh用戶端串連Linux伺服器，就有點兒像Windows下面的遠端連線，但是Linux通過ssh串連上以後是沒有圖形介面，全是命令。

putty

Xshell

使用sftp用戶端來串連sftp服務端，來上傳和下載檔案。(上傳安裝包，修改設定檔上傳。)

winscp

xftp

企業中常用的兩種組合：

putty+winscp

xshell+sftp+manager

面試：使用xshell、putty等ssh用戶端來串連伺服器，使用xftp、winscp等sftp用戶端來上傳和下載檔案，串連和上傳、下載必須依賴於伺服器的ssh、sftp服務，也就是Linux伺服器需要啟動這兩個服務。

2.6.4有沒有使用過雲主機？

使用過，在原來的公司，我們沒有使用自己的伺服器，而是租用阿里的雲主機。

沒有使用過，但有所瞭解。

雲主機就是一些雲端服務電訊廠商(阿里、華為、西部數位、新浪等)，提供的遠端伺服器功能，我們開發人員或者企業只需要按需付費就可以租用對應的伺服器。

使用ssh和sftp來進行操作

2.6.5有沒有做過資料庫最佳化方面的事情？

做過mysql資料庫的最佳化，其他資料庫類似

尋找、定位慢查詢，並最佳化

最佳化手段：

1、建立索引：建立合適的索引，我們就可以在索引中查詢，查詢到以後直接找對應的紀錄。

2、分表：當一張表的資料比較多或者一張表的某些欄位的值比較多並且很少使用時，採用水平分表和垂直分表來最佳化。

3、讀寫分離：當一台伺服器不能滿足需求時，採用讀寫分離的方式來進行叢集。

4、緩衝：使用redis來進行緩衝

5、一些常用最佳化技巧

2.6.6尋找慢查詢並定位慢查詢？

在項目自驗項目轉測試之前，在啟動mysql資料庫時開啟慢查詢，並且把執行慢的語句寫到日誌中，在運行一定時間後，通過查看日誌找到慢查詢語句。

使用explain慢查詢語句，來詳細分析語句的問題

2.6.6資料庫最佳化之遵循範式

資料庫設計時需要遵循方式

什麼樣的表才是符合3NF(範式)

表的範式，是首先符合1NF，才能滿足2NF，進一步滿足3NF

1NF：即表的列具有原子性，不可再分割，即列的資訊，不能分解，還要資料庫是關係型資料庫(mysql/oracle/db2/sybase/sql server)，就自動滿足1NF，關係型資料庫中是不允許分割列的。

2NF：表中的記錄是唯一的，通常我們設計一個主鍵來實現

3NF：即表中不要有冗餘資料，就是說，表的資訊，如果能夠被推匯出來，是不應該單獨的設計一個表欄位來存放。

反3NF：沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降低範式標準，適當保留冗餘資料庫，具體做法是：在概念資料庫模型設計時遵守第三範式，降低範式標準的工作放到物理資料模型設計時考慮，降低範式就是增加欄位，允許冗餘。比如：訂單和訂單項、相簿瀏覽次數和照片的瀏覽次數

2.6.7選擇合適的儲存引擎

在開發中，我們經常使用的儲存引擎myisam/innodb/memory

MyISAM儲存引擎

如果表對事物要求不高，同時是以查詢和添加為主的，我們考慮使用myisam儲存引擎，比如bbs中的發帖表，回複表。

INNODB儲存引擎：

對事務要求高，儲存的資料都是重要資料，我們建議使用INNODB，比如訂單表，帳號表

Memory儲存引擎

我們資料變化頻繁，不需要入庫，同時又頻繁的查詢和修改，我們考慮使用memory，速度極快。

問MyISAM和INNODB的區別(重要)

1、事務安全 myisam不支援事務而innodb支援

2、查詢和添加速度 myisam不用支援事務就不用考慮同步鎖，查詢和添加的速度快

3、支援全文檢索搜尋 myisam支援，innodb不支援

4、鎖機制 myisam支援表鎖，innodb支援行鎖

5、外鍵 MyISAM不支援外鍵，INNODB支援外鍵(通常不設定外鍵，通常是在程式中保證資料的一致)

2.6.8資料庫最佳化之建立合適的索引

索引(index)是協助DBMS高效擷取資料的資料結構

分類：普通索引/唯一索引/主鍵索引/全文索引

普通索引：允許重複的值出現

唯一索引：除了不能有重複的記錄外，其他和普通索引一樣(使用者名稱，身份證，email，tel)

主鍵索引：是隨著設定主鍵而建立的，也就是把某個列設為主鍵的時候，資料庫就會給該 列建立索引，這也就是主鍵索引，唯一且沒有null值

全文索引：用來對錶中的文本域(char，varchar，text)進行索引，全文索引針對MyISAM

explain select * from articiles match(title,body) against(‘database’)【會使用全文索引】

2.6.9索引使用小技巧

索引弊端：

1、佔用磁碟空間

2、對dml(插入、修改、刪除)操作有影響，變慢

使用情境：

a、肯定在where條件經常使用，如果不做查詢就沒有意義

b、該欄位內容不是唯一的幾個值(sex)

c、欄位內容不是頻繁變化

具體技巧：

1、對於建立的多列索引(複合索引)，不是使用的第一部分就不會使用索引

alter table dept add index my_ind(dname, loc); //dname 左邊的列，loc 就是右邊的列

explain select * from dept where dname = ‘aaa’ 會使用到索引

explain select * from dept where loc = ‘aaa’ 就不會使用到索引

2、對於使用like的查詢，查詢如果是’%aaa’不會使用到索引，而’aaa%’會使用到索引

explain select * from dept where dname like ‘%aaa’ 不會使用索引

explain select * from dept where dname like ‘aaa%’ 會使用索引

所以在like查詢時，關鍵字的最前面不能使用% 或者_ 這樣的字元，如果一定要前面有變化的值，則考慮使用全文索引

3、如果條件中有or，有條件沒有使用索引，即使其中有條件帶索引也不會使用，換言之，就是要求使用的所有欄位，都必須單獨使用時能使用索引。

explain select * from dept where dname =‘aaa’;

explain select * from dept where loc = ‘aaa’;

explain select * from dept where deptno = ‘102’;

select * from dept where dname =‘xxx’ or loc = ‘xx’;

select * from dept where dname =‘xxx’ or deptno = 45;

select * from dept where dname =‘xxx’ or loc = ‘xx’ or deptno = ‘45’;

4、如果列類型是字串，那一定要在條件中將資料使用引號引用起來，否則不使用索引。

explain select * from dept where dname =‘111’;

explain select * from dept where dname = 111; 數值自動轉字串

explain select * from dept where dname = ddd; 報錯

5、如果mysql估計會使用全表掃描要比使用索引快，則不使用索引

表裡面只有一條資料

2.6.10資料庫最佳化之分表

分表分為水平(按行)分表和垂直(按列)分表

根據經驗，mysql表資料一般達到百萬層級，查詢效率會很低，容易造成表鎖，甚至堆積很多串連，直接掛掉；水平分表能夠很大程度減少這些壓力。按行資料進行分表。

如果一張表中某個欄位值非常多(長文本、二進位等)，而且只有在很少的情況下會查詢。這時候就可以把欄位多個單獨放到一個表，通過外部索引鍵關聯起來。垂直分表。

考試詳情，一般我們只關注分數，不關注詳情。

水平分表策略：

1.按時間分表

這種分表方式一定有一定的局限性，當資料有較強的高效性，如微博發送記錄、訊息記錄等，這種資料很少有使用者會查詢幾個月前額資料，如就可以按月分表。

2.按區間範圍分表

一般在有個的自增id需求上，如按照user_id水平分表

table_1 user_id 從1~100w

table_2 user_id 從101~200w

table_3 user_id 從201~300w

3.hash分表

通過一個原始目標的ID或者名稱通過一定的hash演算法計算出資料存放區表的表名，然後訪問相應的表。

按如下分10張表

2.6.11資料庫最佳化之讀寫分離

一台資料庫支援的最大並發串連數是有限的，如果使用者並發訪問太多，一台伺服器滿足不了要求時就可以叢集處理，mysql的叢集處理技術最常用的就是讀寫分離。

主從同步

資料庫最終會把資料持久化到磁碟，如果叢集必須確保每個資料服務器的資料是一致的，能改變資料庫的操作都要往主要資料庫去寫，而其他資料庫從主要資料庫上同步資料。

讀寫分離

使用負載平衡來實現寫的操作都往主要資料庫去，而讀的操作往伺服器去。

2.6.12資料庫最佳化之緩衝

在持久層(dao)數資料庫(db)之間添加一個緩衝層，如果使用者訪問的資料已經緩衝起來時，在使用者訪問時直接從緩衝層中擷取，不用訪問資料庫，而緩衝是在操作記憶體級的，訪問速度快

作用：減少資料庫伺服器壓力，減少時間。

Java中常用的緩衝有，

1.Hibernate的二級緩衝，該緩衝不能完成分布式緩衝

2.可以使用redis作為中央緩衝。

2.6.13語句最佳化小技巧

DDL最佳化：

1、通過禁用索引來提供匯入資料效能，這個操作主要針對有資料庫的表，追加資料

//去除鍵

alter table test3 disable keys;

//批量插入資料

insert into test3 select * from test;

//恢複鍵

alter table test3 enable keys;

2、關閉唯一檢驗

set unique_checks=0 關閉；

set unique_checks=1 開啟；

3、修改事務提交方式(匯入)(變多次提交為一次)

set autocommit=0 關閉

set autocommit=1 開啟

DDL最佳化

insert into test values(1,2);

insert into test values(1,3);

insert into test values(1,4);

//合并多條為一條

insert into test values(1,2),(1,3),(1,4);

DQL最佳化

Order by最佳化

1、多用索引排序

2、普通結果排序(非索引排序

group by最佳化

是使用order by null 取消預設排序)

子查詢最佳化

在客戶列表找到不在支付列表的客戶

在客戶列表找到不在支付列表的客戶，查詢沒買過東西的客戶

explain select * from customer where customer_id not in (select distinct customer_id from payment) #子查詢 --這種事基於func外鏈

explain select * from customer c left join payment p on(c.customer_id=p.customer_id) where p.customer_id null --這種事基於“索引”的外鏈

Or最佳化

在兩個獨立索引上使用or的效能優質

1、or兩邊都是用索引欄位判斷，效能好

2、or兩邊，有一邊不用，效能差

3、如果employee表的name和email這兩列是一個複合索引，但是如果是：name=”A” or email=”@” 這種方式，不會用到索引！

limit最佳化

select film_id,description from film order by title limit so,s;

select a.film_id,a.description from film a inner join(select film_id from film order by title limit so,s) b on a.film_id=b.film.id;

2.6.14批量插入幾百萬資料怎麼實現

原理：

1、變多次提交為一次

2、使用大量操作

2.6.15有沒有使用過redis？redis是什麼

redis是一個key-value的nosql資料庫，先存到記憶體中，會根據一定的策略持久化到磁碟，即使斷電也不會遺失資料庫，支援的資料類型比較多

主要用來做快取資料庫的資料和web叢集時當做中央緩衝存放session。

2.6.16簡單說一下redis的使用情境

緩衝：

把經常需要查詢的，很少修改的資料，放到讀速度快的空間(記憶體)，以便下次訪問減少時間，減輕壓力，減少訪問時間。

計數器：

redis中的計數器是原子性的記憶體操作

可以解決庫存溢出的問題。進銷存系統庫存溢出

session快取服務器：

web叢集時作為session快取服務器

緩衝隊列等

2.6.17redis對象儲存方式

json字串

需要把對象轉換為json字串，當字串處理，直接使用set、get來設定或者擷取

優點：設定和擷取比較簡單

缺點：沒有提供專門的方法，需要把對象轉換為json(jsonlib)

位元組

需要做序列化，就是把對象序列化為位元組儲存

如果是資料完全可以使用JSON方式，畢竟redis直接set、get使用起來門檻低很多，redis是沒有提供專門的設定對象方法，需要自己進行改寫。

如果是擔心json轉對象會消耗資源的情況，這個問題需要考量幾個地方，

第一點：就是使用的json轉換lib是否就會存在效能問題

第二點：就是資料的資料量層級，如果儲存百萬級的大資料對象，建議採用儲存序列化對象方式，如果是少量的資料級對象，或者是資料對象欄位不多，還是建議採用json轉換成string方式。

畢竟redis對儲存字元類型這部分最佳化的非常好，具體採用的方式與方法，還是要看你所使用的情境。

2.6.18redis資料淘汰機制

在redis中，允許使用者佈建最大使用記憶體大小server.maxmemory，在記憶體限定的情況下是很有用的，譬如，在一台8G機子上部署了4個redis服務點，每一個服務點分配1.5G的記憶體大小，減少記憶體緊張的情況，由此擷取更為穩健的服務。

記憶體大小有限，需要保持有限的資料

redis記憶體資料集大小上升到一定大小的時候，就會實施資料淘汰策略，redis提供6中資料淘汰策略。

volatile-lru：從已設定到期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰

volatile-ttl：從已設定到期時間的資料集（server.db[i].expires）中挑選將要到期的資料淘汰

volatile-random：從已設定到期時間的資料集（server.db[i].expires）中任意選擇資料淘汰

allkeys-lru：從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰

allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰

no-enviction（驅逐）：禁止驅逐資料

redis 確定驅逐某個索引值對後，會刪除這個資料並，並將這個資料變更訊息發布到本地（AOF持久化）和從機（主從串連）。

2.6.19Java訪問redis

1、使用jedis java用戶端訪問redis伺服器，有點類似通過jdbc訪問mysql一樣。

2、當然如果是spring進行叢集時，可以使用spring data來訪問redis，spring data只是對jedis的二次封裝

2.6.20redis叢集

當一台資料無法滿足要求，可以使用redis叢集來處理，類似於mysql的讀寫分離

 

java面試⑦進階部分