リリースされたばかりの PHP 上級面接の質問はこちらです! 【回答を添付しました】

実は最近も働いているのですが、退職手続き中なので履歴書を出したのですが提出していませんでした。招待状を見て、自分とマッチした数名と面接したところ、次々とオファーをいただきました。面接での質問の波を思い出してください。どの面接で受けたか忘れてしまった方もいたため、カテゴリーごとに分けました。記載されている質問はどれも印象的な質問で、中には忘れてしまった方もいます。答えが間違っている場合は、修正してください。 (詳細:PHP 面接の質問の概要)

<strong>mysql</strong>

1 。 SQL ステートメントを記述するときに注意する必要がある点について話します。

回答:
1. * を選択してください 質問: クライアントに必要なものをすべて提供し、余分なフィールドを提供しないでください。この状況により、インデックスをカバーできたステートメントがカバーされなくなる可能性もあります。カバーインデックスに移動できるようになります。
2. インデックスが無効になるため、クエリ ステートメントのフィールドに対して関数操作を実行しないでください。
3. mysql の自動型変換 ('9' =9 など) は必ず避けてください。
4. null を使用すると、mysql に余分な判断層が発生するため、可能であれば、null を許可するフィールドを設定しないようにしてください。 5. like を使用する場合、ワイルドカード文字 %
が先頭にある場合は、テーブル全体のスキャンも実行されます。

追加歓迎です。

2. 先ほどインデックス作成について話しましたが、インデックス作成について知っているスキルをいくつか教えてください

回答:
1. 区別性の高いフィールドに焦点を当てます。インデックスを作成します。そうでないと、インデックスは意味がありません。
2. 文字列インデックスを作成するときは、サイズに注意してください。インデックスの長さが長すぎると、より多くのスペースが必要になります。必要に応じて、文字列インデックスをインターセプトしてインデックスを作成できます。欠点は、カバー インデックスができないことです。業務に応じて適切にアレンジしてください。

3. 共同インデックスを作成するときは、左端のプレフィックスの原則を知っておく必要があります (名前、電子メール、電話番号など) 最終的には、共同インデックスは (名前)、(名前、電子メール)、 (名前、電子メール、電話番号)、他の人はテーブル全体にのみアクセスでき、共同インデックスの順序はビジネスに基づいて適切に設定する必要があります。

3. インデックスの基礎となるデータ構造は何ですか?

答え: B ツリー。

4. 赤黒ツリーなどではなく、B ツリーが使用されるのはなぜですか?

回答: 赤黒の木を使用できます。ただし、これによりツリーの高さが高くなりすぎる可能性があり、同じクエリに対してより多くのディスク I/O が実行され、パフォーマンスに影響しますが、B ツリーはツリーの高さを維持することができます。高すぎる。この質問に対する答えはあまり良くありませんが、それ以上のものです。追加することは歓迎です。

5. インデックス プッシュダウンをご存知ですか?

本質的に、これはテーブルに返す必要がある通常のインデックスの最適化です。つまり、インデックス ポインターを走査するプロセス中に、エンジン層は最初にいくつかの優先順位を判断し、フィルターで除外します。条件を満たさないものはディスク IO を削減できます。

6. データベースを操作している人が誤って間違ったステートメントを実行し、大量のデータを誤って削除してしまった場合、この時点でデータベースを復元できるでしょうか?回復する方法。

回答: まず、bin-log をオンにする必要があります。オンになっていない場合、回復できない可能性があります。特定のファイル システムを復元できるかどうかによって異なります。 bin-log が有効な場合、タイプ設定は行または混合に設定する必要があり、ステートメントは設定できません。その後、行が誤って削除された場合、対応する削除イベントを挿入イベントに置き換えてスタンバイ データベース上で実行できます。テーブルが誤って削除された場合は、最初に最新の完全バックアップを取得し、それをスタンバイ データベースに配置し、次に bin ログを取り出すことができます。削除されなかったイベントを除き、他のイベントは順番に再生されます。 。

7. ステートメントに設定できないのはなぜですか?

回答: ステートメントに設定します。実際のビンログには、SQL ステートメント (特に削除されていない主キー ID) が保存されます。この場合、マスター/スレーブ アーキテクチャの場合、マスターとスレーブ適切なインデックスが選択されない可能性があり、同じ結果としてマスターとスレーブの不一致が発生します。

8. 先ほどマスター/スレーブについて話しましたが、次にマスター/スレーブ動作のメカニズムについて話してください

回答: まず第一に、メイン ライブラリにはまだ必要なものがあります。 bin-log を開き、スレーブを開きます ライブラリは、まず接続するメイン ライブラリを設定し、マスターを変更します...そして、start smile を実行します このとき、スレーブ ライブラリは 2 つのスレッド、1 つの io_thread を作成します。メインデータベースへの接続を担当します。 sql_thread は主にリレー ログ ステートメントの実行を担当します。まず、メイン ライブラリはスレーブ ライブラリから同期要求を受信し、渡された bin-log ファイル名と同期が開始される場所に従ってバイナリ ファイルをスレーブ ライブラリに送信します。スレーブ ライブラリ io_thread は受信したデータを配置する責任があります。転送ログに転送し、sql_thread が転送ログから実行を読み取って解析し、実行が完了すると同期位置フラグが更新されます。

9. マスタースレーブ遅延をご存知ですか?遅延がかなり長くなる場合もあります。このような状況に遭遇した場合はどうすればよいでしょうか? ###

回答: この種の質問には注意してください。重要なポイントを作成します。問題が発生し、解決策を探している場合、適切な解決策を処方する必要がありますが、言い換えれば、この問題はどのような状況でマスタースレーブ遅延が発生するのかを考えることができます。
1. マスターデータベースとスレーブデータベースのサーバー構成が異なり、スレーブデータベースも異なる場合、遅延時間が長くなる可能性があります。この時点では、同じサーバー構成サーバーに変更するだけです。
2. スレーブ ライブラリに対するプレッシャーが大きすぎます。一般的にはマスタースレーブ方式が採用されており、クエリには基本的にスレーブライブラリが使用され、例えばオペレータや開発者がスレーブライブラリに対して一連のSQL操作を実行する場合があります。それは簡単です。圧力を共有するためにさらにいくつかのスレーブ ライブラリ (1 つのマスターと複数のスレーブ) を割り当てます。 ＃＃＃３．大変な事です。たとえば、delete ステートメントは制限によって制限されるべきではありません。データの量が大きすぎると、メイン ライブラリの実行とスレーブ ライブラリへの同期に時間がかかります。この時間間隔は長すぎます。

デザイン パターン<strong></strong>

普段どのデザイン パターンを使用しているか知っていますか?あなたのビジネスシナリオに基づいて説明していただけますか?

回答: ここではまず、日常生活での Laravel の使用例を示します。これは、ファサード、組み合わせ、装飾、オブザーバーなどの多くのデザイン パターンを使用します...特定のシナリオを想定し、以前のビジネス シナリオに基づいて話します。話しましょう... 最後に、デザイン パターンは特効薬ではないと言いました。適切なシナリオで適切なパターンを使用することによってのみ、その価値が反映されます。

#手書きアルゴリズム<strong></strong>ソートされた配列と指定された値が与えられた場合、指定された値を返します。 インデックス配列内の位置、または存在しない場合は、指定された値を配列に挿入した後のインデックス位置を返します。時間の複雑さに注意してください。

たとえば、順序付けされた配列 [1,3,5,6] と指定された値 5 が与えられた場合、添え字 2 を返します。

順序付けされた配列 [1,3,5] が与えられたとします。 , 6] 値 7 を指定すると、添え字 4 を返します。

回答:

    function searchInsert($nums, $target) {
        if (!count($nums))  return 0;
        $l=0;
        $r = count($nums)-1;
        while ($l <= $r){
            $middle = $l + (($r - $l) >> 1);
            if ($nums[$middle] == $target) return $middle;
            if ($nums[$middle] < $target){
                $l = $middle+1;
            }else{
                $r = $middle-1;
            }    
        }
        return $l;
    }

通常、二分法を使用でき、時間計算量は O(log2n) です。空間複雑度 O(1)。

ネットワーク<strong></strong>

1. トランスポート層の主なプロトコルは何ですか?

回答: 主に TCP プロトコルと UDP プロトコルがあります。両者の違いは、TCP では接続に 3 ウェイ ハンドシェイクが必要であり、メッセージの信頼性を確保できることです。 UDP は接続を必要とせず、メッセージの信頼性も保証しません。

2. TCP の 3 ウェイ ハンドシェイク全般について話してもらえますか?

回答: まず、サーバーは特定のポートをリッスンし、クライアントは (初めて) syn データ パケットを送信するリクエストを開始します。サーバーはこのデータ パケットを受信し、syn を返します。 /ack データ パケットをクライアントに送信し (2 回目)、最後にクライアントは ack パケットを再度送信します (3 回目)。

4. スリーウェイ ハンドシェイクが必要なのはなぜですか?

回答: 主に双方が正常に受信できているかを確認するためです。

初回: クライアントは何も確認できません。サーバーは、クライアントの送受信が正常であること、自身の受信が正常であることを確認できます。
2回目：クライアントは、自身の送受信が正常であること、サーバーの送受信が正常であることを確認できます。サーバーは正常に受信していること、クライアントは正常に送信していることを確認できます。
3回目：すべて確認できました。

同時実行性

1つのアカウントで同時に動作できる入口が複数あると仮定します。 、このアカウントのみ 10元の場合、消費額の過控除を避ける方法は何ですか？未解決の質問については、問題を解決できる限り、それは良い解決策であり、単一の答えはありません。

回答: mysql: where amount>=current_amount および amount>0... を直接使用することも、更新用の悲観的ロックを使用することもできます。 redis:lua スクリプト。 PHP レベルでは、ファイル ロックとキュー機能を使用できますが、消費アウトレットは 1 つだけです。

設計<strong></strong>

社内にログイン機能を備えたプロジェクトが多数ある場合、どのように設計すればよいでしょうか?

回答: このログインは、ログイン センターと同様に、モジュールとして個別に開発する必要があります。他のすべてのサブシステム ログインは、このシステムから認証される必要があります。

その他<strong></strong>

1. プロジェクトで swoole の使用について言及しているかどうかを確認し、それについても書いてください。行って、コルーチンの違いについて話してもらえますか?

回答: 設計は同じですが、主な違いはコルーチン スケジューラ モードです。 Swoole のコルーチン スケジューラはシングルスレッドですが、Go のコルーチン スケジューラはマルチスレッドです。これは、swoole では同時に実行できるコルーチンは 1 つだけですが、go では複数のコルーチンを同時に実行できることを意味します。したがって、swoole コルーチンでグローバル変数をロックする必要はありません。さらに、swoole は基本的にシングルスレッドでマルチプロセスです。つまり、スーパーグローバル変数はなく、プロセスレベルの変数のみがあります。 go マルチスレッドに関して言えば、マルチスレッドでは必然的に重大な変数ロックの問題が発生します。もちろん、go はすぐに使用できる同期読み取り/書き込みロックも提供します。あるいは、代わりにチャネルを直接使用することもできます。

2. go の gmp スケジューリング モデルについて話してもらえますか?

答え: バラバラ 長い間、うまく説明できていないと感じていましたが、よくわかりません。このとき、面接官の心の中では、「知らない」と答えていれば終わっていたのではないかと思います。

3. プロジェクトの最も困難な部分について教えてください。どうやって解決しましたか？

それは、プロジェクトに対するあなた自身の習熟度およびプロジェクトのゴールド コンテンツによって異なります。

以上がリリースされたばかりの PHP 上級面接の質問はこちらです! 【回答を添付しました】の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。