関連する推奨事項: 「2019 PHP 面接の質問まとめ (集)」
1. PHP のガベージ コレクション メカニズム
PHP のメモリ管理は、が自動的に実行され、不要なオブジェクトが削除されます。
PHP は参照カウント GC メカニズムを使用します。
各オブジェクトには参照カウンタ refcount が含まれています。各参照はオブジェクトに接続され、カウンタは 1 ずつ増加します。参照がリビング スペースから出るか、NULL に設定されると、カウンターは 1 ずつ減らされます。オブジェクトの参照カウンタがゼロになると、PHP はそのオブジェクトを使用する必要がなくなったことを認識し、そのオブジェクトが占有しているメモリ領域を解放します。
参考: https://www.php.net/manual/zh/features.gc.refcounting-basics.php
2. セッションとクッキーの違いと関係
相違点:
1. 保存場所: セッションはサーバーに保存され、Cookie はクライアントに保存されます。
2. 保存形式: セッションはオブジェクトの形式でサーバーに保存され、Cookie は文字列の形式でクライアントに保存されます。
3. 目的: Cookie はユーザーの個人設定や趣味などの保存に適しており、Session は顧客認証に適しています
4. パス: セッションはパスを区別できません。ユーザーは Web サイトにアクセスしている間、どこからでもすべてのセッションにアクセスできます。 Cookie にパス パラメータが設定されている場合、同じ Web サイト上の異なるパスにある Cookie は相互にアクセスできません。
5. セキュリティ: Cookie はあまり安全ではありません。ローカルに保存された COOKIE を他人が解析し、COOKIE を欺くことができます。セキュリティを考慮するとセッションを使用する必要があります。
6. サイズと数量の制限: 各番号ドメイン名に含まれる Cookie の数: IE7/8、FireFox: 50、Opera 30; Cookie の合計サイズ: Firefox と Safari では最大 4097 バイトの Cookie が許可され、Opera では最大 4096 バイトの Cookie が許可され、Internet Explorer では最大 4097 バイトの Cookie が許可されます.4095 バイト; 一般に、セッションにはサイズや数量の制限がないと考えられています。
関係:
セッションが正しく動作するには Cookie が必要です。クライアントが Cookie を完全に無効にすると、セッションは無効になります。 Session はアプリケーション サーバーによって維持されるサーバー側の記憶域であるため、ユーザーがサーバーに接続すると、サーバーによって一意の SessionID が生成され、その SessionID がサーバー側の Session 記憶域にアクセスするための識別子として使用されます。 。
セッション ID データはクライアントに保存され、Cookie に保存されます。ユーザーがページを送信すると、セッション データにアクセスするためにセッション ID がサーバーに送信されます。このプロセスには開発者の介入は必要ありません。したがって、クライアントが Cookie を無効にすると、セッションも無効になります。
3. SESSION の生存時間を変更する方法
1. ブラウザの setcookie で保存されたセッション ID の有効期限を設定します (session_name ()、session_id ()、 time () $ lifeTime, "/");
2. SESSION に付属する session_set_cookie_params (86400); を使用して、Session
3 の有効期間を設定できます。 php.ini の .gc_maxlifetime パラメーターの値により、セッションの生存時間が変更される可能性があります
4. PHP ページのリダイレクトのメソッドとは何ですか
header('Location: http://www.baidu.com/') ; echo ''; echo '';
5 . PDO、adoDB、PHPLib データベース 抽象化レイヤーの比較
PHP データベース抽象化レイヤーとは、PHP ロジック プログラム コードと、データベースの基礎となる操作をカプセル化するデータベースとの間のミドルウェアを指します。
PDO は PHP 5.1 をベースに設計されています。基礎的な開発には C 言語が使用されています。PHP の特徴を継承したシンプルで使いやすい設計です。厳密には、PDO は PHP 5 に分類されます。 SPL ライブラリは、MySQL および MySQLi 拡張ライブラリと同様の機能を備えているため、データ抽象化レイヤーとして分類すべきではありません。 PDO は、データベースへの変更が計画されている、または可能性があるシステムでの使用には適していません。
ADODB バックエンドデータベースが何であっても、データベースへのアクセス方法は同じです;
データベースプラットフォームを移行する場合、プログラムコードをあまり変更する必要はありません実際に変更する必要があるのは、データベース構成ファイルだけです。さまざまなデータベースの抽象化層の下部でこれらのステートメントを変換し、さまざまなデータベース方言に適応させることを目的として、多数のアセンブリ メソッドが提供されています。
しかし、この抽象化レイヤーのサイズは大きすぎるようです。ファイルの合計は約 500K です。小規模な Web サイトを作成している場合、これを使用するのはやりすぎのようです。
PHPLib が伴う可能性があります。 PHP による。最も古いデータベース抽象化レイヤー (ただし、ADODB と比較すると、単なる MySQL 抽象クラス ライブラリです)。この抽象クラスは非常に使いやすく、サイズも小さいので、小規模な Web サイト開発に適しています。
PDO は、プリペアド ステートメント クエリ、エラーおよび例外処理、クエリ結果の柔軟な取得 (配列、文字列、オブジェクト、コールバック関数を返す)、SQL 攻撃を防ぐための文字フィルタリング、トランザクション処理、およびストアド プロシージャを提供します。
ADODB は、キャッシュされたクエリ、モバイル レコード セット (HTML、ページング、選択メニューの生成)、トランザクション処理、およびファイルへの出力をサポートします。
参考: http://apps.hi.baidu.com/share/detail/463678
6. 長い接続と短い接続の違いと使い方
長い接続: クライアントとサーバーは最初に接続を確立し、接続が確立された後は切断されず、メッセージが送受信されます。このようにして、通信接続は常に存在します。この方式は P2P 通信でよく使用されます。
短い接続: クライアントとサーバーは、メッセージの送受信トランザクションごとにのみ相互に通信し、トランザクションが完了すると接続はすぐに切断されます。この方法は、ポイントツーマルチポイント通信によく使用されます。 C/Sコミュニケーション。
長い接続と短い接続の使用時間:
長い接続:
短い接続は、主に頻繁な操作、ポイントツーポイント通信、および多数の接続に使用されます。接続数が多すぎることはできません。各 TCP 接続の確立には 3 回のハンドシェイクが必要で、各 TCP 接続の切断には 4 回のハンドシェイクが必要です。操作のたびにコネクションを確立し、再度操作を行うと処理速度が低下するため、TCP コネクションを確立せずに、各操作と次の操作で直接データを送信すれば十分です。例: データベース接続には長い接続が使用されます。短い接続で頻繁に通信するとソケット エラーが発生します。ソケットの頻繁な作成もリソースの無駄です。
短い接続:
Web Web サイトの http サービスは通常、短い接続を使用します。長時間の接続ではサーバーに一定量のリソースが消費されるためです。 Web サイトのように数千、さらには数億のクライアント接続が頻繁に行われる場合、短い接続を使用することでリソースを節約できます。長い接続が使用され、数千のユーザーが同時に使用され、各ユーザーが接続を占有する場合を想像してみてください。サーバーにかかる負荷がどれほど大きいか想像できるでしょう。したがって、同時実行の量は多くなりますが、頻繁な操作が必要ない場合、各ユーザーは短い接続を必要とします。
7. HTTP プロトコルの詳細な説明と応用
http (ハイパーテキスト転送プロトコル) は、ステートレスで、接続が短く、柔軟で、多くの場合、アプリケーション層プロトコルに基づいています。 TCP接続。
参考:https://www.php.cn/faq/437523.html (httpプロトコルの詳細説明)
(HTTPレスポンスのステータスコード)
HTTP 応答ステータス コード
ステータス コードは 3 桁で構成されます。最初の桁は応答カテゴリを定義し、5 つの可能な値があります:
1xx: 命令情報 -- 要求が次の内容を持っていることを示します受信されたため、処理を続行します。
2xx: 成功 -- リクエストが正常に受信、理解され、受け入れられたことを示します。
3xx: リダイレクト -- リクエストを完了するにはさらに操作を実行する必要があります
4xx: クライアント エラー -- リクエストに構文エラーがあるか、リクエストを実行できません
##5xx: サーバー側エラー -- サーバーが法的なリクエストを実行できませんでした 一般的なステータス コード、ステータス 説明と説明: 200 OK // クライアント リクエストは成功しました 400 Bad Request // クライアント リクエストには構文エラーがあるため、サーバーが理解できません##401 Unauthorized // リクエストは未承認です。このステータス コードは WWW-Authenticate ヘッダー フィールドと一緒に使用する必要があります 403 Forbidden // サーバーはリクエストを受信しましたが、サービスの提供を拒否しました
404 Not Found // 要求されたリソースが存在しません。例: input Wrong URL
500 Internal Server Error // サーバーで予期しないエラーが発生しました
503 Server Unavailable // サーバータイムアウト// 通常に戻る可能性があります
304 Not Modified // 要求された Web ページは、最後の要求以降変更されていません。
// サーバーがこの応答を返すとき、Web ページのコンテンツは返されません。
8. 異種システム通信における通信暗号化方式参考:
https://www.php.cn/php-weizijiaocheng-437530. html9. ソケットの接続手順
Socket (ソケット) の概念
Socket (ソケット) は通信の基礎であり、基本的な動作ですTCP/IPプロトコルのネットワーク通信に対応したユニットです。これは、ネットワーク通信プロセスのエンドポイントを抽象的に表現したもので、ネットワーク通信に必要な 5 種類の情報 (接続に使用されるプロトコル、ローカル ホストの IP アドレス、ローカル プロセスのプロトコル ポート、ローカル プロセスの IP アドレス) が含まれています。リモート ホスト、およびリモート プロセスのプロトコル、ポート。
ソケット接続プロセス
ソケット接続を確立するには、少なくとも 1 組のソケットが必要です。そのうちの 1 つはクライアント上で実行される ClientSocket と呼ばれ、もう 1 つはサーバー上で実行される ServerSocket と呼ばれます
ソケット間の接続プロセスは、サーバー監視、クライアント要求、接続確認の 3 つのステップに分けることができます。
サーバー監視: サーバー側ソケットは特定のクライアント ソケットを見つけず、接続を待機している状態で、ネットワークの状態をリアルタイムで監視します。
クライアント要求: クライアントのソケットによって行われる接続要求を指し、接続対象はサーバーのソケットです。これを行うには、クライアントのソケットは、まず接続先のサーバーのソケットを記述し、サーバー側のソケットのアドレスとポート番号を指定して、サーバー側のソケットに対して接続要求を行う必要があります。
接続確認: サーバー側ソケットがクライアント側ソケットからの接続要求をリッスンまたは受信すると、クライアントに応答することを意味します
ソケット要求、新しいスレッドの確立、サーバー側ソケットの記述をクライアントに送信し、クライアントがこの記述を確認すると、接続が確立されます。サーバー側ソケットは引き続き待機状態にあり、他のクライアント ソケットからの接続要求を受信し続けます。
10. TCP プロトコル、3 方向ハンドシェイク、4 方向ウェーブ
TCP プロトコル (伝送制御プロトコル) は、ホスト間の層の伝送制御プロトコルです。 、信頼性の高い接続を提供します。 このサービスは、接続の確立を確認するために 3 ウェイ ハンドシェイクを使用し、切断するために 4 ウェイ ハンドシェイクを使用します。
ビットコードは tcp フラグビットで、マークは
SYN (同期接続確立) 同期
ACK (確認応答確認)## の 6 種類があります。
#PSH (プッシュ送信)FIN (フィニッシュエンド)RST (リセットリセット)URG (緊急緊急)# #11. php の区別と、機能は似ているがパフォーマンスが大きく異なる一般的に使用される関数の例参考: http://apps.hi.baidu.com/share/detail/43169774
12. Posix と perl 互換の正規表現の比較と関数のパフォーマンス分析#POSIX 正規表現と PCRE 正規表現の知っておくべき最も重要な違い:
1 . PCRE 関数には、「区切り文字が閉じられている」というパターンが必要です。
2. POSIX 互換の正規表現には修飾子がありません。 POSIX とは異なり、PCRE 拡張機能には大文字と小文字を区別しないマッチングのための専用関数がありません。代わりに、サポートは /i モード修飾子を使用して同じジョブを実行します。他のパターン修飾子を使用して一致戦略を変更することもできます。
3. POSIX 関数は左端から開始して最長一致を検索しますが、PCRE は最初の正当な一致の後で停止します。文字列が一致しない場合は問題ありませんが、一致すると結果と速度に違いが生じます。違いを説明するために、次の例を考えてみましょう (Jeffrey Friedl の Mastering Regular Expressions の本から) パターン one (self)?(selfsufficient)? を使用して文字列 ownsufficient と一致させると、PCRE は自分自身と一致しますが、POSIX を使用すると、結果は次のようになります。文字列全体は自分で十分です。どちらの部分文字列も元の文字列と一致しますが、POSIX では結果として最も長い時間がかかります。
PCRE 使用可能な修飾子: (i,s,m)
13. PERL 正規表現を実装し、HTML ファイルの a タグのすべての href ハイパーリンクをキャプチャします。正規表現: /75378b7ba2451d4b3a25aa37f7ba381d]/is", $html, $matches ); print_r ($matches [1]); // すべてのハイパーリンクを出力します ?> $_SERVER 魔法のメソッド http://apps.hi.baidu.com/share/detail/17851228 get と set マジック変数 http://apps.hi.baidu.com/share/detail/17851228 ディレクトリ 15 . spl 共通データ構造クラス 16. PHPデザインパターン ファクトリパターン ファクトリ パターンは、オブジェクトを作成する特定のメソッドを持つクラスです。 new を直接使用せずに、ファクトリ クラスを使用してオブジェクトを作成できます。このようにすると、作成されるオブジェクトのタイプを変更する場合は、ファクトリを変更するだけで済みます。このファクトリを使用するすべてのコードは自動的に変更されます。 17. 負荷分散された Web アプリケーション サーバーの設計 (youku など) 在 Apache 负载均衡的情况下,做 PHP 开发如何考虑一下几方面: PHP 源文件在服务器、PHP 文件上传处理、相关配置文件、Session 会话放置、日志放置 Apache 负载均衡的原则 轮询均衡策略 (轮询转发请求) 按权重分配均衡策略 (按响应数量转发请求) 权重请求响应负载均衡策略 (按响应流量转发请求) 18. 如何优化前端性能 1) 页面内容的优化 a) 降低请求数 合并 css、js 文件,集成 CSS 图片 b) 减少交互通信量 压缩技术:压缩 css、js 文件,优化图像,减少 cookie 体积; 合理利用缓存:使用外部 js/css 文件,缓存 ajax; 减少不必要的通信量:剔除无用脚本和样式、推迟加载内容、使用 GET 请求 c) 合理利用 “并行” 尽量避免重定向 慎用 Iframe 样式表置于顶部 脚本放到样式后面加载 d) 节约系统消耗 避免 CSS 表达式、滤镜 2) 服务器的优化 a) b) c) d) 19. yahoo 的 34 条前端优化法则 减少 HTTP 请求、利用 CDN 技术、 设置头文件过期或者静态缓存、Gzip 压缩、把 CSS 放顶部、 把 JS 放底部、避免 CSS 表达式、将 JS 和 CSS 外链、减少 DNS 查找、减小 JS 和 CSS 的体积、 避免重定向、删除重复脚本、 配置 ETags、缓存 Ajax、尽早的释放缓冲、 用 GET 方式进行 AJAX 请求、延迟加载组件、 预加载组件、减少 DOM 元素数量、跨域分离组件、 减少 iframe 数量、不要出现 404 页面、减小 Cookie、 对组件使用无 Cookie 的域名、减少 DOM 的访问次数、开发灵活的事件处理句柄、使用 2cdf5bf648cf2f33323966d7f58a7f3f 而非 @import、避免过滤器的使用、优化图片、优化 CSS Sprites、 不要在 HTML 中缩放图片、缩小 favicon. ico 的大小并缓存它、保证组件在 25K 以下、将组件打包进一个多部分的文档中 20. 数据库缓存的基本理论,参考 memcached 什么是 Memcached? memcached 是高性能的分布式内存缓存服务器。一般的使用目的是,通过缓存数据库查询结果,减少数据库访问次数,以提高动态 Web 应用的速度、提高可扩展性。 虽然 memcached 使用了同样的 “Key=>Value” 方式组织数据,但是它和共享内存、APC 等本地缓存有非常大的区别。Memcached 是分布式的,也就是说 它不是本地的。它基于网络连接(当然它也可以使用 localhost)方式完成服务,本身它是一个独立于应用的程序或守护进程(Daemon 方式) PHP 与 Memcached Memcached 使用 libevent 库实现网络连接服务,理论上可以处理无限多的连接,但是它和 基于反向代理的 Web 缓存; 基于反向代理的 Web 缓存 21. PHP 安全模式 php 安全模式:safe_mode=on|off 启用 safe_mode 指令将对在共享环境中使用 PHP 时可能有危险的语言特性有所限制。可以将 safe_mode 是指为布尔值 on 来启用,或者设置为 off 和脚本尝试访问的文件的 UID,以此作为限制机制的基础。如果 UID 相同,则执行脚本;否则,脚本失败。 当启用安全模式时,一些限制将生效 1、 所有输入输出函数(例如 fopen ()、file () 和 require ())的适用会受到限制,只能用于与调用这些函数的 脚本有相同拥有者的文件 2、 如果试图通过函数 popen ()、system () 或 exec () 等执行脚本,只有当脚本位于 safe_mode_exec_dir 配置指令指定的目录才可能 3、HTTP 验证得到进一步加强,因为验证脚本用于者的 UID 划入验证领域范围内。此外,当启用安 全模式时,不会设置 PHP_AUTH。 4、如果适用 MySQL 数据库服务器,链接 MySQL 服务器所用的用户名必须与调用 mysql_connect () 的文件拥有者用户名相同。 以下是一些和安全模式相关的配置选项 22. 常见的 web 攻击方式 常见攻击 XSS (Cross Site Script) ,跨站脚本攻击。它指的是恶意攻击者往 Web 页面里插入恶意 html 代码,当用户浏览该页之时,嵌入的恶意 html 代码会被执行,从而达到恶意用户的特殊 目的。 XSS は受動的攻撃であり、受動的であり悪用するのが難しいため、多くの人がその有害性を無視することがよくあります。しかし、フロントエンド テクノロジーが継続的に進歩し、リッチ クライアントのアプリケーションが増加するにつれて、この問題はますます注目を集めるようになりました。 簡単な例: あなたが現在 SNS サイトのユーザーであり、情報公開機能に脆弱性がある場合、悪意のあるスクリプトを入力すると js を実行できます。この瞬間、あなたを現在見ている人全員が、新しい情報を受け取る人のブラウザがこのスクリプトを実行し、プロンプト ボックスをポップアップ表示します (非常にクールなポップアップ広告:))。もしあなたがもっと過激なことをした場合、その結果は次のとおりです。想像を絶することになる。 CSRF (クロスサイト リクエスト フォージェリ)、クロスサイト偽造リクエスト。名前が示すように、ユーザーは自分の ID を使用して、ユーザーの知らないうちに接続リクエストを偽造することで攻撃者が達成する必要のある目的の一部を達成することができます。 csrf の攻撃は、攻撃者のアクティブな動作によってトリガーされる必要がある xss csrf の攻撃とは異なります。どうやら「釣られている」疑惑があるようだ。 マルチウィンドウ ブラウザは、開いた新しいウィンドウに現在のセッションがすべて含まれているため、暴政に寄与している疑いがあるようです。IE6 のような単一のブラウザ ウィンドウであれば、そのような問題は発生しません。各ウィンドウは独立したプロセスです。 簡単な例を挙げてください: あなたは白人社会をプレイしていて、誰かがリンクを送信しているのが見えます。それをクリックすると、ギフトを送るためのフォームがこのリンク内に偽造されます。これは単なる単純な例です。質問 目に見える一般。 Cookie ハイジャック。ページの権限を取得することで、ページ内に悪意のあるサイトへの簡単なリクエストを書き込み、ユーザーの Cookie を保持し、Cookie を取得した後は、Cookie を介して盗まれたユーザーとしてサイトに直接ログインできます。これはクッキーのハイジャックです。 簡単な例を挙げてみましょう: 誰かが非常に興味深い日記を書き、それをみんなと共有しました。多くの人がクリックして日記を表示し、共有しました。すべてが正常に見えましたが、日記を書いた人はそうではありませんでした 他の目的のため, サイト外へのリクエストがログにこっそり隠されています。その後、このログを読んだ人は誰でも知らないうちに自分の Cookie を誰かに送信し、その後誰にでも渡すことができます。Cookie を使用してこの人のアカウントにログインします。 SQL インジェクション攻撃 SQL インジェクション攻撃では、ユーザーはフォームまたは GET クエリ文字列を操作してデータベース クエリに情報を追加します。 DNS 攻撃 サービス拒否攻撃 サービス拒否攻撃とは、攻撃者がターゲット マシンにサービスの提供を停止させようとすることを意味し、一般的な攻撃手法の 1 つです。ハッカーによって使用されます。 攻撃者はサービス拒否攻撃を実行し、これによりサーバーは実際に 2 つの効果を得ることができます: 1 つはサーバーのバッファを強制的に満杯にし、新しいリクエストを受け入れないようにすること、もう 1 つは IP スプーフィングを使用してサーバーに正規ユーザーの接続を強制的にリダイレクトするリセット、正規ユーザーの接続に影響 23. PHP アンチホットリンク防止の基本的な考え方 内容ホットリンクですか? ホットリンクとは、サービスプロバイダー自体がサービスを提供していないコンテンツを指し、技術的手段を使用して、他の有益なエンドユーザーインターフェイス(広告など)をバイパスし、自社の Web サイト上で他のサービスをエンドユーザーに直接提供します。 . プロバイダーのサービス内容を偽ってエンドユーザーの閲覧率やクリック率を騙し取っています。受益者はリソースをまったく提供しないか、ほとんど提供しませんが、実際のサービスプロバイダーは何の利益も受け取りません。 Web サイトのホットリンクは、盗まれたリンク Web サイトの帯域幅を大量に消費し、実際のクリックスルー率は非常に低くなり、盗まれたリンク Web サイトの利益に重大な損害を与える可能性があります。ホットリンクを防ぐにはどうすればよいですか? ファイルやディレクトリの名前を不規則に変更する 参照ページを制限する 原則として、サーバーはユーザーが送信した情報の Web サイトのアドレスを取得し、それを実際のサーバーと比較します。アドレスが一致している場合は、サイト内または信頼できるサイトに対して送信されたことを意味し、そうでない場合はホット リンクとみなされます。実装する場合、HTTP_REFERER1 および htaccess ファイル (mod_Rewrite を有効にする必要がある) を正規表現と組み合わせて使用し、ユーザーの各アクセス要求に一致させることができます。 ファイル カモフラージュ ファイル カモフラージュは現在最も一般的に使用されているリーチング対策テクノロジであり、通常はサーバー側の動的スクリプト (PHP/JSP/ASP) と組み合わせられます。実際、ユーザーが要求したファイル アドレスは偽装されたスクリプト ファイルであり、このスクリプト ファイルはユーザーの要求を認証し、一般にホットリンクかどうかを判断するための基礎としてセッション、Cookie、または HTTP_REFERER をチェックします。実際のファイルは実際にはユーザーがアクセスできない場所に隠されており、ユーザーが検証に合格した後にのみユーザーに返されます。 暗号化認証 この不正侵入防止方法は最初に取得されます。ユーザー情報は、クライアントから認証として要求されたファイル名とその情報に基づいて文字列 (セッション ID) に暗号化されます。認証が成功した後にのみ、サーバーはユーザーが必要とするファイルをクライアントに送信します。通常、暗号化されたセッションIDをURLパラメータの一部としてサーバーに渡しますが、このセッションIDはユーザーの情報と紐付けられているため、たとえ他人がリンクを盗んでもセッションIDは身元認証を通過できず、セキュリティ対策が実現されます。 -リーチの目標。この方法は、分散ホット リンクに非常に効果的です。 ランダムな追加コード 每次,在页面里生成一个附加码,并存在数据库里,和对应的图片相关,访问图片时和此附加码对比,相同则输出图片,否则输出 404 图片 加入水印 24. HTTP 请求头信息和响应头信息 请求头信息 响应头信息 25. MySQL MySQL 数据库性能优化 使用 mysqlreport; 正确使用索引:explain 分析查询语句,组合索引,索引副作用(占空间、update) 开启慢查询日志、使用慢查询分析工具 mysqlsla; 索引缓存、索引代价(插入更新索引); 表锁,行锁,行锁副作用(update 多时候变慢),在 select 和 update 混合的情况下,行锁巧妙解决了读写互斥的问题; 开启使用查询缓存; 修改临时表内存空间; 开启线程池; MySQL Query 语句优化的基本思路和原则 1、优化需要优化的 Query; 2、定位优化对象的性能瓶颈; 3、明确优化目标; 4、从 Explaing 入手; 5、多使用 Profile; 6、永远用小结果集推动大的结果集; 7、尽可能在索引中完成排序; 8、只取自己需要的 Columns; 9、仅仅使用最有效的过滤条件; 10、尽可能避免复杂的 Join 和子查询。 MySQL 中 MyISAM 引擎和 InnoDB 引擎的区别以及它们的性能 1:Innodb 支持事物,Myisam 不支持 2:锁定机制不一样,Myisam 支持表锁定,而 Innodb 支持行锁 3:Myisam 不支持外键,Innodb 能支持 4:Myisam 能在特定环境下支持全文索引,而 Innodb 不支持 5:Myisam 支持数据压缩,Innodb 不支持 6:在数据存储上,Myisam 占用的空间少,Innodb 相对多些 7:Myisam 在批量插入和查询方面速度上有优势,而 Innodb 由于支持行锁,所以在数据修改方面更胜一筹 MySQL 存储引擎 MyISAM:不支持事务、表锁和全文索引,操作速度快 InnoDB:行锁设计、支持外键、支持安全事务 HEAP:数据存放在内存中,临时表 NDB Cluster:MySQL 的簇式数据库引擎 CSV: 存储引擎把数据以逗号分隔的格式存储在文本文件中。 FEDERATED:存储引擎表并不存放数据,它只是指向一台远程 MySQL 数据库服务器上的表 Archive: 只支持 INSERT 和 SELECT 操作,压缩后存储,非常适合存储归档数据 Merge:允许将一系列等同的 MyISAM 表以逻辑方式组合在一起,并作为 1 个对象引用它们 表类型,区分表类型 优化表设计的常用思路 负载均衡的数据库设计 数据类型及详细定义,区分 26. Apache 性能优化,配置,fastCGI 等几种工作模式 27. Ajax 用 JS 实现 Ajax 功能 28. Javascript 变量、作用域、作用域链.
#14. 定義済み変数、マジック変数、マジックメソッドの比較とその効果例
isset と unsetcall と callStatic__clone__toString スリープとウェイクアップ__invoke
クラス関数メソッド名前空間
参考:https://www.php.cn/php-weizijiaocheng-437532.html
safe_mode_gid=on|off
safe_mode_include_dir=string
safe_mode_env_vars=string
safe_mode_exec_dir=string
safe_mode_protected_env_vars=string
POST /scp1.1.0/prs/new_rnaseqtask/run_go HTTP/1.1
Host: 172.30.4.102
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0
Accept: /
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Referer: http://172.30.4.102/scp1.1.0/index.php/prs... Content-Length: 1819
Cookie:
ci_session=a%3A4%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22e31556053ff9407a454f6a1e146d43eb%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A12%3A%22172.16.23.42%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A50%3A%22Mozilla%2F5.0+%28Windows+NT+6.1%3B+rv%3A6.0%29+Gecko%2F2010010%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1314955607%3B%7D664b51a01ef99bac95f3e2206e79cb00;PHPSESSID=v33mlm1437lmop1fquta675vv4;username=linjinming; tk=1314955601855 Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Fri, 02 Sep 2011 09:27:07 GMT
Server: Apache/2.2.3 (Red Hat)
X-Powered-By: PHP/5.1.6
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 31
Connection: close
Content-Type: text/html; charset=UTF-8
var createXHR = function(){
}
var addURLParam = function(url, name, value){
}
var xhr = createXHR();
xhr.onreadystatechange = function(){
}
var url = 'testAjax.php';
addURLParam(url, 'name', 'linjm');
xhr.open('get',url,true);
xhr.send(NULL);
if(xhr.readyState == 4){ } if(xhr.status > 200 && xhr.status < 300 || xhr.status == 304){ } alert(xhr.responseText); url += (url.indexOf('?') == -1 ? '?' : '&'); url += encodeURIComponent(name) + '=' + encodeURIComponent(value); return url; if(window.XMLHttpRequest){ } return new XMLHttpRequest(); return new ActiveXObject('Microsoft.XMLHTTP'); throw new Error('No XMLHttpRequest available'); }else{ }else{}