PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
RDBにおけるキャッシュという考え方
RDBの専門家として日々活動している中で気づいたことのひとつに、「RDBはデータへのアクセスの実装をインデックスに頼っているが、インデックスは全ての問題を解決できるほど万能ではない」ということがある。インデックスというのはとても強力な部品であり、その点には全く異論はない。だが、世の中の全ての問題（クエリ）を解決できるほど、柔軟性に富んだものではないということだ。RDBは、どのインデックスを使ってデータへアクセスするかということを、オプティマイザを用いて判断する。大抵のRDB製品では、オプティマイザはよい仕事をするので、インデックスとオプティマイザの組み合わせによって、ほとんどの問題に対応できる。だが、100%ではないのであり、そのようなケースがシステムの性能問題を引き起こしたり、プログラマ（アプリケーションの設計者）に、NoSQLへ完全に移行したり、クエリ高速化のために非正規化をすると言っ
DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
GreenBuckets ノード障害時の書き込み可用性を向上させた - blog.nomadscafe.jp
これまで GreenBuckets では、オブジェクトの読み込み時はノードがダウンした場合でも可用性が保たれていましたが、書き込みはオンライン状態にあるノード数がレプリカ数分ないと新規オブジェクトの追加ができませんでした。そのため可用性を保とうと思うと、レプリカ数が2では最低4台、レプリカ数3では最低6台のノードがないと1台でもノードがダウンした場合に書き込みができない状態になっていました。 これでは初期投資が大きくなりすぎるということで、最低2台(レプリカ数2)でも書き込みの冗長性が確保できるようにしてみた。 左の図が、ノード1が障害でオフラインの状態。これまでだとノード1に書き込もうとして失敗するとすぐに保存エラーとクライアントに返していましたが、GreenBucketsを変更して右の図のように、ノード2と3に仮に保存して(1)、新しく設けた Recovery Queue に登録します
Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった
Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。 同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。 Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。 MySQLとCassandraが落選した理由 H
大人のためのInnoDBテーブルとの正しい付き合い方。
InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか？」というものがある。InnoDBはMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
Kazuho@Cybozu Labs: MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話
« フレンド・タイムライン処理の原理と実践 | メイン | MySQL の ORDER BY を高速化 » 2008年06月12日 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 フレンド・タイムライン処理の原理と実践 の続きです。 先のエントリでは、プルモデルの速度が当初予測していたよりも遅かった (というより SQL レイヤでのオーバーヘッドが大きそうだった) ので、MySQL Internals メーリングリストで質問したりしながら、C++ で直接 InnoDB にアクセスするようなコードを書いてみました。 タイムライン構築速度 タイムライン/秒 SQL そしたら、10倍以上高速に！ ベンチマークを perl ベースのものから mysqlslap に変えたのですが、プッシュモデルの 2/3 の速度が出ています。これなら、データサイズが約 1/10 にな
WordPress を高速化する5つの方法 | Sun Limited Mt.
WordPress を高速化する5つの方法です。 テーマの効率化 PHP の高速化 ページキャッシュプラグインの使用 MySQL クエリキャッシュ MySQL テーブル最適化 テーマの効率化 テーマの効率化というより、出力する HTML や CSS, JavaScript の最適化です。これに役立つ FireFox のプラグインが YSlow です。バックエンド（サーバなど）の最適化よりもフロントエンド（HTML, CSS, JavaScript）の最適化の方が効率的に向上させられるので、真っ先に取り組んでみるべき。 使い方などは下記のページが詳しいです。 【ハウツー】YSlowでWebページを高速化 – リッチさと速さを同時に実現するUIを! (1) YSlowでWebページパフォーマンス計測 | エンタープライズ | マイコミジャーナル PHP の高速化 PHP アクセラレータという
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践
« MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の「マイミクシィ最新日記」やはてなブックマークの「お気に入り」等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下「フレンド・タイムライン」と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。本記事では、「フレンド・タイムライン」を実現する、プッシュ型とプル型の二種類の手法について、その原
coLinuxの容量拡張 - それマグで！
coLinuxのデフォルトだとIMGが１GBですぐに足りなくなる。 Ubuntuでaptitude dist-upgradeをやったら全然足りない。 そこでこれを試した WindowsのCMDから # 約2GBの空ファイル作成 C:\Program Files\coLinux >fsutil file createnew ubuntu01.img 2000000000 #fedoraとかubuntu01とか名前は任意でOK、あとで変えればいいし coLinuxの起動設定ファイルにこれを追加 cobd1="C:\Program Files\coLinux\ubuntu01.img" # confに追加 colinux起動したらrootになって以下を実行 root$>dd if=/dev/cobd0 of=/dev/cobd1 # colinuxで実行(元のcobd0 を cobd1 にコピ
hori-uchi.com: mysqldumpで文字化けしないためのメモ
ローカルの開発環境で使っていたMySQLなんですが、何も考えずデフォルトの設定で使っていたら、mysqldumpした際に、データが文字化けして、ちょっとは待ったのでメモ。 MySQLのバージョンは4.1.20。 文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。 僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。 なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。 この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
「MySQL AB :: The Most Demanding Web 2.0 Sites in the World Run MySQL
Contact Sales USA - Toll Free: +1-866-221-0634 USA - From abroad: +1-208-327-6494 USA - Subscription Renewals: +1-866-830-4410 Latin America: +1 512 535 7751 UK: +44 845 399 1124 Ireland: +353 1 6919191 Germany: +49 89 420 95 98 95 France: +33 1 70 61 48 95 Sweden: +46 730 207 871 Benelux: +358 50 5710 528 Italy: +39 06-99268193 Israel: +358 50 5710 528 Spain & Portugal: + 34 933905461
MySQL :: MySQL 8.0 リファレンスマニュアル :: 17.1.2 バイナリログファイルの位置ベースのレプリケーションの設定
ソースで、バイナリロギングが有効になっていることを確認し、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.1「レプリケーションソース構成の設定」を参照してください。 ソースに接続する各レプリカで、一意のサーバー ID を構成する必要があります。 これには、サーバーの再起動が必要となる場合があります。 セクション17.1.2.2「レプリカ構成の設定」を参照してください。 必要に応じて、レプリケーション用のバイナリログを読み取るときに、ソースとの認証中にレプリカで使用する別のユーザーを作成します。 セクション17.1.2.3「レプリケーション用ユーザーの作成」を参照してください。 データスナップショットを作成したり、レプリケーションプロセスを開始したりする前に、ソースで現在の位置をバイナリログに記録するようにして
mysql を高速化したいときに読むメモ (TechKnowledge)
給料の振込口座として三井住友銀行に口座を持っています。自動支払いサービスを使用して光熱費等の公共料金の支払いをしていますが、先日それらの内の一つを失念してたことに気づきました。口座を確認した時にはすでに引き落としが完了していたため、手元の資金が心細くなった状態で数日を過ごさなければなりません。三井住友銀行で即日キャッシングが可能であれば、是非利用したいのですが。 運が良ければ、三井住友銀行の即日キャッシングは可能 三井住友銀行の特徴はまずクレジットカード会社との連携したサービスが魅力的なことがあげられます。キャッシングでは銀行カードローンですから、何より安い金利が大きい利点になります。概ね銀行系の審査に必要な時間は長くなるようですが、三井住友銀行ではカード発行が当日に行なってくれます。 三井住友銀行は即日キャッシングができるかと言うと微妙なことになります。申込から審査結果の連絡までは、土日
MySQL :: MySQL 4.1 リファレンスマニュアル :: 5.2 SELECT ステートメントおよびその他のクエリの最適化
第 1 にすべてのクエリに影響を及ぼすことが 1 つあります。アクセス権システムのセットアップの複雑性が増すほど、オーバヘッドも増加します。 GRANT ステートメントを何も実行していない場合は、MySQL によってアクセス権チェックが多少最適化されます。大量の処理が必要なときは、GRANT を使用しないことで時間を節約できる場合もあります。GRANT を使用した場合は、アクセス権チェックが多くなり、オーバヘッドが増加します。 明示的な MySQL 関数に関わる問題がある場合は、常に MySQL クライアントでこの関数の計時を行うことができます。 mysql> SELECT BENCHMARK(1000000,1+1); +------------------------+ | BENCHMARK(1000000,1+1) | +------------------------+ | 0
phpMyAdmin 2.7.0-pl2 - ドキュメント
Navigation index next | phpMyAdmin 5.1.4 documentation » Welcome to phpMyAdmin’s documentation!¶ Contents: Introduction Supported features Shortcut keys A word about users Requirements Web server PHP Database Web browser Installation Linux distributions Installing on Windows Installing from Git Installing using Composer Installing using Docker IBM Cloud Quick Install Verifying phpMyAdmin releases
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
memo-space :: SQLでIPアドレスから携帯のキャリアを判定する
MySQLのスロークエリを分析する「MySQA」:phpspot開発日誌