精“服務”之道，通“技術”之理

 

 
小的時候我總在想一件事，一些體育比賽為什么沒有辦法超越前面的人，為什么大家還要學習，還要不停的舉辦比賽，一個小孩子怎么學習也沒有大人跑的快，跳的高，投的遠，為什么他們還是不停的練習，后來我發現，我們學習的目的不是為了超越他人，而是為了戰勝自己，超越自己，讓自己的潛能達到最大限度的發揮，讓自己體驗一把全力以赴的人生。
 
這個問題源自我們的企業，艾銻無限，做了十多年的企業，忽然發現超越自己的企業有無數家，那我怎么做都難以做到這個世界的第一名，這樣思考下去越做越有壓力，越做越覺得沒有什么意思，因為一切都會過去，即使爭得第一又能怎樣呢？
 
不過當領悟到人生活著的真諦時，我發現企業存在的價值與人生完全一樣，這個世界需要不同的人種，不同的語言，不同的性格，不同的思想，我們才會覺得有意義，我們才會覺得有無限探索的機會，如果全都一樣，可能沒有一個人愿意活好幾十年。在電影《后五百年中》那些透過DNA的克隆人，每一個人都一樣，活著唯一的意義就是忙著死去。這樣的人生又有誰想要過呢.


其實企業也一樣，這個世界需要有不同的企業，需要有個性的企業，需要有獨特領悟的企業，只有這樣才能讓每一個不同的人去選擇的時候有更多的空間和機會。才能讓這個世界五彩繽紛，才能讓所有人活得多姿多彩，才能讓大家覺得這是一個無限可能性的世界。
 
從我們開始經營艾銻無限的時候，就發現原來服務他人是件很幸福的事，特別當我們為別人解決了他們很久困擾的問題，當他們看到問題已被解決，臉上露出了久違的笑容的時候，我們心里滿滿的，那是一種無法用語言表達的幸福。經過十幾年錘煉，我們曾經在服務過程中有過被誤會，有過被不理解，有過被不認同，但每當想起那一張張笑臉，我們又重新鼓起勇氣，重拾信心，繼續前行，因為我們深知十年磨一劍，梅花香自苦寒來的道理.
 

今天每一位艾銻人都知道誠心、細心、貼心三心服務是艾銻無限的服務之道，是經的起檢驗的服務標準，是5000多家客戶體驗后并極其認可的服務系統，我們認為服務不僅僅是解決客戶遇到的問題，更需要解決客戶遇到問題后著急的心，只要心處理好了，問題自然而然也就沒有了。
 

 
技術是門學問，但好技術更是門藝術，真正的技術不僅僅是企業帶來更高的效率，創造更大的價值，還能為整個社會創造一種全新的生產方式，蒸汽機取代了農耕時代，讓我們有了工廠和比馬跑的更快拖的更多貨的車，我們稱這次變革為“第一次工業革命”，100多年后人類社會生產力發展又一次重大飛躍，人們把這次變革叫做“第二次工業革命”，人類由此進入“電氣時代”。這個時代產生了汽車和飛機，讓我們的速度和效率發生了天翻地覆的變化.而第三次是科技的革命,并且一直延續到新千年，讓整個人類進入信息時代。接下來我們很快就會發生“第四次科技革命” ，這次將以技術和數據驅動整個世界，而人將在這次革命中并非是主角，當“阿法狗”打敗世界圍棋冠軍的時候，我們可能已經意識到這個時代的來臨，技術將不僅僅是技術，技術將會引領人類的發展和變革，用好了就是藝術，用不好有可能就是一場災難.
 

 
所以我們期望透過技術服務，找到服務人類的規律，而不是取代人類，讓更多人失業，而是讓人類因技術變得更強大.

IT系統數據庫運維：MyISAM與InnoDB 的區別

 
 
區別：
1. InnoDB支持事務，MyISAM不支持，對于InnoDB每一條SQL語言都默認封裝成事務，自動提交，這樣會影響速度，所以最好把多條SQL語言放在begin和commit之間，組成一個事務； 
 
2. InnoDB支持外鍵，而MyISAM不支持。對一個包含外鍵的InnoDB表轉為MYISAM會失敗； 
 
3. InnoDB是聚集索引，使用B+Tree作為索引結構，數據文件是和（主鍵）索引綁在一起的（表數據文件本身就是按B+Tree組織的一個索引結構），必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數據。因此，主鍵不應該過大，因為主鍵太大，其他索引也都會很大。MyISAM是非聚集索引，也是使用B+Tree作為索引結構，索引和數據文件是分離的，索引保存的是數據文件的指針。主鍵索引和輔助索引是獨立的。也就是說：InnoDB的B+樹主鍵索引的葉子節點就是數據文件，輔助索引的葉子節點是主鍵的值；而MyISAM的B+樹主鍵索引和輔助索引的葉子節點都是數據文件的地址指針。

4. InnoDB不保存表的具體行數，執行select count(*) from table時需要全表掃描。而MyISAM用一個變量保存了整個表的行數，執行上述語句時只需要讀出該變量即可，速度很快（注意不能加有任何WHERE條件）；
那么為什么InnoDB沒有了這個變量呢？
    因為InnoDB的事務特性，在同一時刻表中的行數對于不同的事務而言是不一樣的，因此count統計會計算對于當前事務而言可以統計到的行數，而不是將總行數儲存起來方便快速查詢。InnoDB會嘗試遍歷一個盡可能小的索引除非優化器提示使用別的索引。如果二級索引不存在，InnoDB還會嘗試去遍歷其他聚簇索引。
如果索引并沒有完全處于InnoDB維護的緩沖區（Buffer Pool）中，count操作會比較費時。可以建立一個記錄總行數的表并讓你的程序在INSERT/DELETE時更新對應的數據。和上面提到的問題一樣，如果此時存在多個事務的話這種方案也不太好用。如果得到大致的行數值已經足夠滿足需求可以嘗試SHOW TABLE STATUS
 
5. Innodb不支持全文索引，而MyISAM支持全文索引，在涉及全文索引領域的查詢效率上MyISAM速度更快高；PS：5.7以后的InnoDB支持全文索引了
 
6. MyISAM表格可以被壓縮后進行查詢操作
 
7. InnoDB支持表、行(默認)級鎖，而MyISAM支持表級鎖InnoDB的行鎖是實現在索引上的，而不是鎖在物理行記錄上。潛臺詞是，如果訪問沒有命中索引，也無法使用行鎖，將要退化為表鎖。
 
例如：    
t_user(uid, uname, age, sex) innodb;     uid PK    無其他索引   
update t_user set age=10 where uid=1;             命中索引，行鎖。    
update t_user set age=10 where uid != 1;           未命中索引，表鎖。    
update t_user set age=10 where name='chackca';    無索引，表鎖。
 
8、InnoDB表必須有主鍵（用戶沒有指定的話會自己找或生產一個主鍵），而Myisam可以沒有
 
9、Innodb存儲文件有frm、ibd，而Myisam是frm、MYD、MYI
        Innodb：frm是表定義文件，ibd是數據文件
        Myisam：frm是表定義文件，myd是數據文件，myi是索引文件
 
如何選擇：
 
    1. 是否要支持事務，如果要請選擇innodb，如果不需要可以考慮MyISAM；
 
    2. 如果表中絕大多數都只是讀查詢，可以考慮MyISAM，如果既有讀也有寫，請使用InnoDB。
 
    3. 系統奔潰后，MyISAM恢復起來更困難，能否接受；
 
    4. MySQL5.5版本開始Innodb已經成為Mysql的默認引擎(之前是MyISAM)，說明其優勢是有目共睹的，如果你不知道用什么，那就用InnoDB，至少不會差。
 
InnoDB為什么推薦使用自增ID作為主鍵？
    答：自增ID可以保證每次插入時B+索引是從右邊擴展的，可以避免B+樹和頻繁合并和分裂（對比使用UUID）。如果使用字符串主鍵和隨機主鍵，會使得數據隨機插入，效率比較差。
 
innodb引擎的4大特性
       插入緩沖（insert buffer),二次寫(double write),自適應哈希索引(ahi),預讀(read ahead)