2015/10/03 phpcon 2015 updated at 2016/01/13 about default_password_lifetime's default will be 0
MySQLの文字コード事情
2015/10/03 phpcon 2015 updated at 2016/01/13 about default_password_lifetime's default will be 0
MySQLのFLOAT型を使う理由が見つからない件 - hnwの日記
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
MySQLで大量のUPDATEを流したい時はELT、FIELDキーワードを用いたBULK UPDATEで高速化 - Qiita
UPDATE heyas SET yatin = 60000 WHERE id = 1; UPDATE heyas SET yatin = 67000 WHERE id = 2; UPDATE heyas SET yatin = 74000 WHERE id = 3; . . .
サイトを37倍に高速化した7つの手法 - オールアバウトTech Blog
今回はオールアバウトのnnmrが弊社サイトAll About Japanの速度を高速化した経緯についてまとめます。 All About Japanとは そもそもAll About Japan（以下AAJ）とは何かといいますと、弊社が提供している訪日外国人向けの日本紹介サイトです。 外国人向けサイトで、英語、中国語（繁体字）、中国語（簡体字）、タイ語、韓国語の5か国語に対応しております。 「Anime」「Izakaya」「Ninja」といったような特集や、実際に観光する人向けのモデルルート記事が特色です。 ■ 特集 (url : http://allabout-japan.com/en/tag/sushi/ ) ■ モデルルート記事 (url : http://allabout-japan.com/en/article/222/ ) 技術的な紹介 LAMP環境です。 （サーバー構成は後に記述
UNIQUE制約(ユニーク制約を設定する)
テーブルを作成するときにカラムに UNIQUE 制約をつけることでカラムに重複した値を格納することができなくなります。ここでは MySQL における UNIQUE 制約の使い方について解説します。 テーブルを作成したあとに UNIQUE インデックスを作成したり、作成したインデックスを削除する方法については「インデックスの作成」を参照してください。
PDOのサンプルで数値をバインドする際にintにキャストしている理由
先日PHPカンファレンス北海道2016にて「『例えば、PHPを避ける』以降PHPはどれだけ安全になったか」と題して基調講演を担当致しました。その際のスライドはこちら。 そうしたところ、以下のご指摘をいただきました。 @ockeghem スライド拝見しました。39番目のスライドですが、バインドのタイミングでintにキャストするのはちょっと例として良くない気がします。意図的にオーバーフローを起こすことで想定外のレコードの取得を許してしまいそうです。キャストしない方がまだ安全だと思うのですが。 SQLデータベースは、int型よりも大きな桁数を扱える場合があるので、intへのキャストを避けた方がよいという指摘は一般論としてはもっともなものだと考えます。PHPの場合、9223372036854775807を越える数字文字列をint型にキャストすると、9223372036854775807が返ります(
俺の脳内選択肢が、SQLインジェクション対策を全力で邪魔している — A Day in Serenity (Reloaded) — PHP, CodeIgniter, FuelPHP, Linux or something
PHP Advent Calendar 2013 in Adventarの19日目です。昨日も私の「PDOでの数値列の扱いにはワナがいっぱい（2）」でした。 うっかりtogetterなんか見てしまい、無駄に時間を使ってしまったと後悔した上に混乱してしまい余計にわからなくなってしまった人もいるかも知れません。 そこで、せっかくの機会なので、SQLインジェクション対策について、現在の私の考えをまとめておこうと思います。 選べ ①SQLインジェクション対策にプリペアドステートメントを使う ②SQLインジェクション対策にエスケープを使う もし、上記のような選択にはまってしまったら、あなたのSQLインジェクション対策は、現実的には、ほぼ100％間違っていると言えるのではないでしょうか。プリペアドステートメントとエスケープは、このような対立構造にはありませんから。 なお、この記事は、SQLインジェクシ
XAMPP/MAMPは不要！チームでの開発に最適なVagrantでの開発環境構築 | 株式会社ウィズモ
こんにちは。しげァsjdasaxnYhsキです。 WEB制作での開発環境について、うちでは案件によりますが、今までは主にXAMPP/MAMPを使用した開発を行っていました。 しかし、時代は流れに流れ、今更ながらPHPでの主な開発環境をMAMPから「Vagrant（ベイグラント）」へ移行させることにしました。 これまでの開発環境の問題点これまでの開発環境についての問題点ですが、よくあるのが以下のようなことでした。 XAMPP/MAMP等でよくある問題点 チームでの開発の場合、それぞれ環境が違うと「あれ、こっち動かないよ」という人がでてくる複数案件を１台でやってるとVirtualHostが溢れるport80が何者かに使われている、そして動かない複数人で環境を揃えるにはそれぞれソフトウェア等のインストールが必要mampなどでの開発環境では、チームでのそれぞれのPHPのバージョンが違ったり、 po
phpMyAdmin最新版を手動インストール - なにそれ日記
yumでインストールできるphpMyAdminは少し古いバージョンなので手動でインストール (^_^) ★使用OS # cat /etc/issue CentOS release 6.6 (Final) ★pypMyAdminをインストールする場所に移動 今回は例として /var/www/ の下にインストールします。 ※ yumでインストールした場合は /usr/share/phpMyAdminになります。 # cd /var/www/ ★phpMyAdmin の公式ページから最新版をダウンロード 公式ページ ：phpMyAdmin - Download 2015/03/05現在の最新版は、2015/03/04 リリースの4.3.11.1。 # wget http://sourceforge.net/projects/phpmyadmin/files/phpMyAdmin/4.3.11.1
[ThinkIT] 第3回：max_connectionsとthread_cacheのチューニングを行う (3/3)
先ほどまでとは違い、Max_used_connectionsは同時接続数の増加と共に増え、最終的には400近くになりました。また、Threads_createdが激減し、ほとんどスレッドが生成されなくなりました。 これがthread_cacheの直接的な効果ですが、それ以上に重要なのはスレッド生成の負荷がなくなったことによって、Queries_per_secが「同時接続数が増加してもばらつきが少なく、数値も低下しにくくなった」という効果があらわれていることです。 データのばらつきは多少あるものの、ひいき目に見れば「Max_used_connections=310程度まではQueries_per_secを維持している」といえるのではないでしょうか。先ほどは128でしたから、単純な数値の比較で約2.5倍の同時接続に耐えうるサーバになったのです。
MySQLバージョンアップのベストプラクティス | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアによる、MySQLバージョンアップの様々なパターンと、その利点・欠点、手順の解説。バージョンアップ実施前の、事前調査とテストが重要であるとの指摘も。 MySQLのバージョンアップ(訳注 : 原文ではupgrade、以下同じ)はどこかで必要になるタスクだし、我々Percona SupportでもMySQLバージョンアップのベストプラクティスについての色々な質問を受け付けている。この記事では、色々なシナリオにおけるMySQLバージョンアップの推奨できる方法に焦点を当ててみたい。 MySQLのバージョンアップはなぜ必要になってしまうのか？その理由は色々だが、新機能が必要、パフォーマンスの改善、バグ修正などがあるだろう。しかし、アプリケーションと組み合わせた上で事前に広範囲なテストをしておかないと、リスクの大きい
データベースのインデックスについてのまとめ(MySQL) | kokonotsu
データベースのインデックスについてのまとめ(MySQL) 恥ずかしながらインデックスについて知識が皆無だったので調べたことをまとめておきます。 とはいっても奥は果てしなく深いので今回は インデックスとは何か メリット、デメリット 使い方 ぐらいの、にわか知識までとします。 ？インデックスとは 特定の絡むデータを複製し検索を行いやすくするもの。 本の目次のようなもので、全ページ(全レコード)見なくても該当のページがわかる。 select文に特別な追加は必要なく、インデックスを貼ったカラムを検索対象としたselect文を実行するだけ。 実行後は先にインデックスを検索し、その情報をもとにテーブルからデータを取得する。 ？メリット、デメリット インデックスを作成しておくと検索が早くなるが全てのカラムに対してインデックスを作成すればいいかというとそうではない。 インデックスを作成するとデータを追加、
013 同一レコードを複数ユーザが同時に変更してしまうのを防ぐには？ - EC-One ナレッジセンター レスキューサービス ブログ
こんにちは、id:EC-OneのAkiです。 梅雨も明けて30度を超える暑い日が続きますが、みなさんいかがお過ごしですか？ アイスの食べ過ぎは夏バテの元ですよ！ 今回は、Webアプリケーションのちょっと生っぽい実装テクニックのお話です。 同一レコードを複数ユーザが同時に変更してしまう？ データベース内の特定のレコードを変更するWebアプリケーションを考えてみます。たとえば、「取引先マスタの変更」を行うアプリケーション等です。 この場合、このアプリケーションは以下のような流れになるでしょう。 ユーザがデータ編集画面に入るボタンをクリック。 サーバが現在のデータをデータベースから取得＆返却し、それをユーザのブラウザが表示する。 ユーザがデータを編集し、編集結果反映ボタンをクリック。 このとき、変更した項目も変更していない項目も一緒にサーバに送られる。 サーバが編集結果をデータベースに反映する。
クソクエリを燻り出す - Studio3104::BLOG.new
非効率なクエリが投げられてMySQLサーバが悲鳴をあげることがあります。 DBAは、そんなときに「こんなクソクエリ投げてんじゃねーよ(ノ｀Д´)ノ彡┻━┻」と言えるようにダメクエリを探し出せるようにしておく必要があります。 スロークエリログ スロークエリログを出力するようにする my.cnfにこのように書いておくと、実行に指定時間以上を要したクエリが指定ファイルに出力されるようになります。 ※MySQL5.0以前のバージョンは書き方が異なるので注意 この例では、「実行に0.5秒以上かかったクエリを/var/log/mysql/slow.logに吐く」ようになります。 [mysqld] slow_query_log=1 slow_query_log_file=/var/log/mysql/slow.log long_query_time=0.5 漢(オトコ)のコンピュータ道: MySQL 5
mysqldump --single-transaction に --flush-logs をつけてはいけない - tmtms のメモ
(いまだに時々ブクマされていたりしますが、これはバグで MySQL 5.5.21 以降では修正されています。) mysqldump は MySQL のデータのバックアップを取得するコマンドです。 mysqldump に --single-transaction を指定すると一貫性を保持したバックアップを取得することができます*1。 この時に mysqldump が発行しているクエリは次のような感じです。 [mysqldump --single-transaction DB名] SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ START TRANSACTION WITH CONSISTENT SNAPSHOT UNLOCK TABLES DB選択 テーブルからデータの読み込み「START TRANSACTION WITH CON
unoh.github.com by unoh
いつの間にか会社で古株になったyamaokaです。 webアプリケーションのバックエンドにMySQLを使っている場合、 クエリ（SQL）のチューニングをする必要がありますよね。 皆さんはチューニングの計画をどのように立てていますか。 もちろん、既に明らかに重いことが想定されているページがあれば、 その処理で使われているクエリを中心にEXPLAINなどを使って解析していけばいいと思います。 でもそうではなく、全体的にクエリの見直しやチューニングを行いたい場合は 実際に実行されているクエリを確認していくという作業が必要です。 そこで使うことができる3つの方法について書きたいと思います。 遅いクエリを記録する MySQLにはスロークエリログといって、 実行に時間がかかったクエリを記録する機能が最初から付いています。 /etc/my.cnfに次のように設定を書けば実行時間が1秒を超えたクエリが出力
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Osclassの評判と実態｜サイト制作の専門家が徹底解説！【2023年最新版】｜PRONIアイミツ
MySQLチューニング
When to switch from MyISAM to InnoDB?
Is there a graceful or safe restart for mysql like for apache httpd?