Captcha security check stack3.com is for sale Please prove you're not a robot View Price Processing
Captcha security check stack3.com is for sale Please prove you're not a robot View Price Processing
CentOS6.2に phpMyAdminをソースからインストールする方法です。 環境 CentOS6.2 Apache 2.2.15 phpMyAdmin 3.5.0 php 5.3.10 mysql 5.5.22 ダウンロードと設置1 2 3 4 wget http://sourceforge.net/projects/phpmyadmin/files/phpMyAdmin/3.5.0/phpMyAdmin-3.5.0-all-languages.tar.gz/download tar zxvf phpMyAdmin-3.5.0-all-languages.tar.gz mv phpMyAdmin-3.5.0-all-languages /var/www/phpMyAdmin chown -R apache:apache /var/www/phpMyAdmin/ 以下
以降のセクションでは、MySQL レプリケーションでサポートされていることとされていないことに関する情報、および特定のステートメントの複製時に発生する可能性がある固有の問題と状況に関する情報を提供します。 ステートメントベースレプリケーションは、ソースとレプリカの間の SQL レベルでの互換性に依存します。 つまり、ステートメントベースのレプリケーションが成功するには、使用される SQL 機能がソースサーバーとレプリカサーバーの両方でサポートされている必要があります。 現在のバージョンの MySQL でのみ使用可能なソースサーバーで機能を使用する場合、以前のバージョンの MySQL を使用するレプリカにレプリケートすることはできません。 このような非互換性は、リリースシリーズ内およびバージョン間でも発生する可能性があります。 MySQL 8.0 と以前の MySQL リリースシリーズの間で
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
LIMIT 20 OFFSET (:page - 1) * 20 みたいなクエリは :page に大きい値が入れれるように設計されてるとクエリに殺されるので、 WHERE key = :offset_for_next_page LIMIT 20 なクエリになるよう設計してほしい。 http://twitter.com/kamipo/status/56304601049210880 俺もボスに教わるまで知らなかったのだが、 mysql> select id from mentions order by id asc limit 100, 10;がすることは、 データを10個だけfetchする ではなく、 110個データをfetchして、先頭から100個捨てる だ。何を今更って感じですよねー知ったのは10ヶ月ほど前でした。俺の未熟さを思い知れ。 で。このようにlimitを付けてデータを取得する
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1+InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト:今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip:元テキストをgzipコマンドで圧縮したものです。 MyISAM:記事をMyISAMのテーブルに
REPLACE INTOが実はINSERT + DELETEだったと思ったら、結局DELETE + INSERTだった REPLACE INTOが実はINSERT + DELETEだった(INSERTが先で後から消す)の続き。 REPLACE INTOは「DELETE + INSERT(その行を消してからもう一度書く)」だと今まで思っていたけれど、 実は「INSERT + DELETE(行を突っ込んでから古い行を消す)」な動きっぽいというはなし。 そっちが先なんだびっくりー、という感じで書いたのですが、 色々手落ちがあったので後から調べたことをメモ。 1) その結果だと時間が一緒だから、「DELETEトリガーがINSERTトリガーより先」というのは断言できない。順番は必ずしも保証されないから。 ⇒TRIGGERの中身をSYSDATE(6)に書き換えてみました。 mysql56> delim
TIMESTAMP カラムは DATETIME カラムと同じフォーマットで表示されます。言い換えると、表示幅は 19 文字に決められていて、形式は 'YYYY-MM-DD HH:MM:SS' です。 TIMESTAMP 型の値は、格納するときに現在のタイムゾーンから UTC に変換され、取り出すときに UTC から現在のタイムゾーンに変換されます。(この変換が行われるのは、TIMESTAMP データ型の場合だけで、DATETIME などのほかのデータ型では行われません。)デフォルトでは、接続ごとの現在のタイムゾーンはサーバーの時刻です。タイムゾーンの設定は、MySQL Server Time Zone Supportに説明されているように、接続ごとに行うことができます。タイムゾーン設定が一定であるかぎり、格納した値と同じ値を復帰させることができます。TIMESTAMP 値を格納したあとで、
innodbのcount遅い?遅くないしっ!Σ(゚д゚lll) 2013/7/24 2015/9/7 MySQL 「MySQLのinnodbはcountすると遅い」…という知識だけが先行してしまい、イケてない設計をしてしまった。。。 それは、ソーシャルアプリでよくある「未確認通知数」を算出するために発生した。 ↓こーいうの パッと思いついた設計は以下の3つ。 通知テーブルに確認フラグを持っておき、未確認の件数をcountする。 ☆メリット :シンプル。生産性&保守性UP。 ★デメリット:速度が遅い(と思っていた)。 KVSに未確認件数を保持しておく。 ☆メリット :速度が速い。 ★デメリット:KVSはトランザクションが無いので整合性の保障がない。 専用のテーブル&列を作ってカウントアップ・ダウンする。 ☆メリット :取得対象が1レコードなので速度が速い。 ★デメリット:同一ユーザへのアクシ
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
hogeテーブルをhoge_20081123というテーブルにコピーする方法。 /* hogeテーブルのスキーマをコピーしてテーブル作成 */ > CREATE TABLE hoge_20081123 LIKE hoge; /* hogeテーブルのデータをINSERT */ > INSERT INTO hoge_20081123 SELECT * FROM hoge; たまにしかやらないのですが、いっつも忘れているのでメモ。 実践ハイパフォーマンスMySQL 第3版 作者: Baron Schwartz,Peter Zaitsev,Vadim Tkachenko,菊池研自(監訳),株式会社クイープ 出版社/メーカー: オライリージャパン 発売日: 2013/11/25 メディア: 大型本 この商品を含むブログ (6件) を見る
2009年5月20日水曜日 MySQLでSELECTするときにLIMITをつけると速度が上がるのか。 どうか。ということを疑問に思いました。 ブックマークの処理速度の向上を目指してあれこれ見てはいるのですが。 こまごまとSQLを引いていて、そもそも全体的な引き方が悪いんじゃないかとも思ってくる次第・・・ まぁ、それは今更なのでSQL文ひとつひとつを確認していくのですが。 SELECT文でLIMITをつけるつけないで処理速度って変わるのですかね。 いろいろ検索してみたのですが結局わからず終い。 やったほうが早いのでやってみました。 【SELECT * FROM `テーブル` WHELE `カラム`= 'Google' 】 と 【SELECT * FROM `テーブル` WHELE `カラム`= 'Google' LIMIT 1】 結果は歴然。 0.0663 と 0.0014 でした。 エェー
Using Mod_Auth_MySQL with Apache 2 and Debian Firstly if you haven't alrteady done so throw some of the essentials on such as Apache 2 / PHP 4 / MySQL #apt-get install libapache2-mod-php mysql-server php4-mysql libapache2-mod-auth-mysql Next we need to enable the module, unlike Apache 1, we don't need to modify any configuration files to add sometype of LoadModule statement, simply: #cd /etc/apach
このエントリーはMySQL Casual Advent Calendar 2013 10日目の記事です。カジュアル! このへんでそろっとカジュアル詐欺と言われるのを防止するために、カジュアルな話を書いてみました。 MySQL5.6も正式リリースされてもうすぐ1年経ち、5.7の足音も聞こえてきている今日このごろですが皆様のMySQLのご機嫌はいかがでしょうか。 新機能や性能向上/bugfixに対応するためにMySQLのバージョンアップを行う機会や性能や不具合調査を行うことも多いかと思います。データベースのバージョンアップは特にメジャーバージョンアップの場合、パラメータのデフォルト値などの変更や仕様変更の影響(オプティマイザの変更)をアプリケーションが受けないか、性能の変化などを検証すると思います。 検証 実際に検証を行う場合、本番環境で流れているクエリをバージョンアップ先のDBに実際に流して
MySQLの列挙できるデータ型としてSET型とENUM型があります。 ま、入るデータを限定できるという利点はあるんですけど、 この使い道の違いがなんなのかちょっと謎。 で、調べてみると ENUM型 … リストの中から一つ選ぶ … ラジオボタン SET型 … リストの中から選ぶ … チェックボックス という感じです。 実際、ENUMはChar型でデータを保存して、SET型はビット列で 保存するみたいです。ビットが立ってるやつが選択されてる、 といった具合ですね。 フォームの値をそのまま格納できるらしいので、便利ですよね。 もっと早く知っていればよかった…。 MySQL :: MySQL 5.1 リファレンスマニュアル :: 10.4.4 ENUM タイプ http://dev.mysql.com/doc/refman/5.1/ja/enum.html エンタープライズ:MySQL独自のENU
MySQL で新たにテーブルを作ったり、プライマリキー、ユニーク制約、またはインデックスを作成する際、下記のようなエラーが発生することがあります。 ERROR 1170 (42000): BLOB/TEXT column 'text_field' used in key specification without a key length 結論として回避策から書くと、BLOB型またはTEXT型の場合は、インデックス作成時にキー長を明示してあげる必要があります。 create index new_index on table_name(text_field(100)); このエラーは、MySQL が BLOB型もしくはTEXT型 (これらに順ずる TINYTEXT型 や LONGTEXT型を含む)のような可変長カラムでは、その先頭から最大255文字分しかインデックスできないという制約から来て
mysql> CREATE TABLE test -> ( -> id INT NOT NULL auto_increment, -> name VARCHAR(64), -> email VARCHAR(320) NOT NULL, -> password VARCHAR(32) NOT NULL, -> primary key (id) -> ); Query OK, 0 rows affected (0.00 sec) mysql> ALTER TABLE test ADD CONSTRAINT uq_test UNIQUE KEY (email, password); ERROR 1071 (42000): Specified key was too long; max key length is 1000 bytes mysql>
photo by byte MySQLといえば、巷ではInnoDBばかり注目され、MyISAMの地下アイドル化がにわかに語られる今日この頃、皆様いかがお過ごしでしょうか。 まあカジュアルにストレージエンジンを変換するだけで済むなら、簡単なのです。 -- legacy_my_tableをInnoDBストレージエンジンに変換する ALTER TABLE legacy_my_table ENGINE=InnoDB; よし終わった!さあランチタイムだ! ・・・と片付けてしてしまうと、悲劇が起こるかもしれません。(>o<;) それでは本日、MyISAMからInnoDBへ移行するなら知っておきたい意外な落とし穴とTipsを紹介します。 AUTO INCREMENTの挙動が違う落とし穴 以下に該当するクエリを利用している場合には、注意が必要です。私はハマりました。 INSERT IGNORE INTO
1. MySQL Admin が見た Devs の常識、 DBA は非常識 2013/09/14 yoku0825@MyNA PHP Conference 2013 2. \こんにちは!/ ● yoku0825 ● とある企業の DBA ● MySQL 歴 5 年くらい ● オラクれない ● ポスグれない ● 嫁の夫 ● せがれの父 ● 日本 MySQL ユーザ会 (MyNA) のスベり担当 3. \しゃべること!/ ● 日常的に MySQL のソースコードに触れる変態 DBA がフツーの Devs に投げた愛のマサカリ集 ( のつもり ) ● ウチの開発言語は PHP > Java >> Ruby らしいです ● ウチでは DBA がサーバーの構築、 Devs が設計・ テーブル構築・運営、 DBA はトラブルシュートや改 善提案 ( 運用 ) 、というサイクルで回しています。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く