給定一個升序排列的自然數(shù)數(shù)組，數(shù)組中包含重復(fù)數(shù)字，例如：[1,2,2,3,4,4,4,5,6,7,7]。問題：給定任意自然數(shù)，對數(shù)組進(jìn)行二分查找，返回數(shù)組正確的位置，給出函數(shù)實現(xiàn)。注：連續(xù)相同的數(shù)字，返回第一個匹配位置還是最后一個匹配位置，由函數(shù)傳入?yún)?shù)決定。

我為什么會出這道題目？

    二分查找在數(shù)據(jù)庫內(nèi)核實現(xiàn)中非常重要

    在數(shù)據(jù)庫的內(nèi)核實現(xiàn)中，二分查找是一個非常重要的邏輯，幾乎99%以上的SQL語句(所有索引上的范圍掃描/等值查詢/Unique查詢等)，都會使用到二分查找進(jìn)行數(shù)據(jù)的定位。

    考慮一個數(shù)據(jù)庫表t1(a int primary key, b int)，表上的b字段有一個B+樹索引，表中記錄的b字段取值，就是題目中的[1,2,2,3,4,4,4,5,6,7,7]序列。此時，給定以下的兩條查詢語句，就是使用到了不同的二分查找邏輯：

    SQL1：  

 select * from t1 where b > 4;

    SQL2： 

select * from t1 where b >= 4;

    針對SQL1，索引的二分查找，就需要跳過所有的4，從最后一個4之后開始返回所有記錄；針對SQL2，二分查找就需要定位到第一個4，然后順序讀取所有記錄。

    除此之外，針對數(shù)據(jù)庫中其他的查詢邏輯，二分查找還需要附帶更多的功能，例如：

    SQL3： 

select * from t1 where b < 2;

    SQL4：

 select * from t1 where b <= 2;

    由于數(shù)據(jù)庫索引同時支持反向掃描，因此SQL3、SQL4的語句，都可以使用索引反向掃描。反向掃描時，SQL3需要定位到索引中的第一個2；而SQL4，則需要定位到索引的最后一個2，然后開始反向返回滿足查詢條件的索引記錄。
    二分查找在程序設(shè)計中，是一個十分基礎(chǔ)并且易錯的功能

    第一個真正正確的二分查找算法，在第一個二分查找實現(xiàn)之后的12年，才被發(fā)表出來。通過Google，輸入Binary Search或者是二分查找關(guān)鍵字，有大量的相關(guān)的文章或者博客討論此話題。

二分查找實現(xiàn)，需要注意的問題

本文不準(zhǔn)備詳細(xì)介紹一個正確的二分查找應(yīng)該是如何實現(xiàn)的，畢竟現(xiàn)在網(wǎng)上有著大量的正確版本。接下來，根據(jù)批改試卷過程中發(fā)現(xiàn)的一些問題，做一些簡單的分析，希望對大家實現(xiàn)一個有效的二分查找算法，甚至是一個數(shù)據(jù)庫內(nèi)可用的二分查找算法，有所幫助。
問題一：是否檢查參數(shù)的有效性

大量的試卷，在給出此問題的解決算法時，直接拿著low，high參數(shù)開始進(jìn)行計算，但是卻沒有檢查low/high參數(shù)。low/high是否相同，數(shù)組中是否存在記錄？low/high構(gòu)成的區(qū)間是否有效？代碼的魯棒性不足。

在數(shù)據(jù)庫的二分查找實現(xiàn)中，一般是對一個索引頁面進(jìn)行二分查找。索引頁面中有可能根本不存在用戶的記錄(索引頁面中的記錄全部被刪除，又沒有與兄弟頁面合并時)，此時，low/high均為0，此時如果根據(jù)low/high計算出來的mid進(jìn)行記錄的讀取，就存在邏輯錯誤。
問題二：二分查找中值的計算

這是一個經(jīng)典的話題，如何計算二分查找中的中值？試卷中，大家一般給出了兩種計算方法：

算法一： mid = (low + high) / 2

算法二： mid = low + (high