MySQL のテーブル定義から外部キー制約を推測するツールを作った - ブログ・ア・ラ・クレーム
GW 中の自分へのプチ課題として、表題の通りのツール hakagi(葉鍵, Leaf and Key) を作りました。ツール名には特に意味はありません。 github.com テーブル名やカラム名から外部キー制約を張れるような気がするカラムを選出し、制約追加のための ALTER TABLE をするクエリを吐き出したりします。 なぜ作ったのか 外部キー制約は言うまでもなくデータの不整合を避けるのに有用ですが、いくつかの理由からこれを用いない選択肢も存在すると思われます。 この辺りについては以下の記事なども参考にすると良さそうです。 我々(主語が大きい)は何故MySQLで外部キーを使わないのか MySQLで外部キー制約を課すべきか - リジェクトされました 外部キー制約を設けないことによるデメリットも幾つか生じると思っていて、その一つで自分が気になっている点として、「ER 図をツールで自動生成
Top 20+ MySQL Best Practices | Envato Tuts+
Database operations often tend to be the main bottleneck for most web applications today. It's not only the DBA's (database administrators) that have to worry about these performance issues. We as programmers need to do our part by structuring tables properly, writing optimized queries and better code. In this article, I'll list some MySQL optimization techniques for programmers. Before we start,
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.2.2 DATE、DATETIME、および TIMESTAMP 型
DATE、DATETIME、および TIMESTAMP 型は関連しています。 このセクションでは、これらの特徴、似ている点、および異なる点について説明します。 MySQL は、セクション9.1.3「日付リテラルと時間リテラル」で説明している複数の形式で、DATE、DATETIME、および TIMESTAMP 値を認識します。 DATE および DATETIME 範囲の説明では、「サポートされている」とは、以前の値は機能するが、保証はないということを意味します。 DATE 型は、日付部分を含むが時間部分は含まない値に使用されます。 MySQL は、DATE 値を'YYYY-MM-DD'形式で取得して表示します。 サポートしている範囲は '1000-01-01' から '9999-12-31' です。 DATETIME 型は、日付と時間の両方の部分を含む値に使用されます。 MySQL は、DA
MySQLのタイムゾーン - tmtms のメモ
YAPC::Asia 2015 のセッションで、MySQL のタイムゾーンの話が出ていましたが、以前タイムゾーン周りで少しはまったことがあったのを思い出したので書いてみます。 MySQLのデフォルトのタイムゾーンは mysqld 起動時のシステム設定です。TZ 環境変数の値か、変数が設定されていなければ /etc/localtime(Ubuntu の場合) です。 # TZ=Japan /usr/sbin/mysqld mysql> SHOW VARIABLES LIKE '%time_zone%'; +------------------+--------+ | Variable_name | Value | +------------------+--------+ | system_time_zone | JST | | time_zone | SYSTEM | +---------
AWS RDS MySQL のタイムゾーンが UTC の状態で DATETIME フィールドに JST で入れてしまった場合の復旧 - Qiita
AWS RDS MySQL のタイムゾーンが UTC の状態で DATETIME フィールドに JST で入れてしまった場合の復旧MySQLRDSタイムゾーン アプリは JST でいきたい場合。 結論 アプリで、MySQLの現在時刻取得を使っているか調査。NOW(), SYSDATE() など 使ってないなら、おそらく AWS - RDS(MySQL)でJSTを使う たった１つの冴えたやり方 - Qiita この対応でOK。RDSの再起動不要。 使っているなら、UTC で評価されているのが意図したものか調査。 → JST で処理されていると勘違いしているなら、上記対応の実施でOK 。(今回の僕のケース) → 意図していたなら、アプリのコードの修正必要。 経緯 Amazon Web Service の RDS で MySQL を使っています。 MySQL 内で、NOW() を実行した時に U
サーバーがUTCなのでMySQLのタイムゾーンが気になって調べた | kanonjiのブログ
AWSのサーバーを使うようになって、あまり気にしてなかったMySQLのタイムゾーンが気になるようになってきました。 というのも、今やってるプロジェクトでは、AWSのインスタンスに入れたOS（Linux）のタイムゾーンは、UTCのままにしておく事に決まっていて、そうするとMySQLのタイムゾーンもUTCのままの方が良さそう。もしかしたらタイムゾーンの変更が出来ないAmazon RDSのMySQLを使うかもしれないし。 なので、ちょっとMySQLのタイムゾーンがUTCだとどうなるか、調べてみました。 Amazon RDS for MySQLでタイムゾーンを設定するのはやめたほうがいいかもしれない – Qiita ちなみに、Amazon RDS（MySQL）のタイムゾーンの変更は、一応いくつか方法があるみたいだけど、トラブルの元にもなるみたいなので、UTCのままで使う方を検討した方が良さそう
MySQLのXAトランザクションについて調べていた(1) - ぱいぱいにっき
ドキュメント MySQL :: MySQL 5.6 Reference Manual :: 13.3.7 XA Transactions 英語読めないから5.1の日本語ドキュメントも併用して読んでいる。 検証環境 MySQL 5.6.22 REPEATABLE-READ 使い方 ゆるふわWebアプリケーションエンジニアなもんで、幸か不幸か今までのエンジニア人生で複数DB環境(シャーディング/マスタDB分散)に遭遇したことがない。なのでXAの使い方をドキュメントから読み取っていく。 XAトランザクションの流れ 普通のトランザクションではBEGINで始めるが、XAトランザクションの場合は mysql> XA START 'xid'; で始める。 で、このxidってやつは何なのかというと、上記ドキュメントでは xid: gtrid [, bqual [, formatID ]] とあり、gtri
もしもデータベースサーバがクラッシュしたら
人の作ったものは完璧ではない。完璧でないものはクラッシュする。故にデータベースはクラッシュする。サーバハードウェアの故障、OSのクラッシュ、データベースそのもののバグなど原因は様々であるが、永遠に停止することなく動き続けるRDBMSというものは存在しない。もちろん数年間無停止で問題が出ない場合もあるが、クラッシュするときはするので対策が必要である。もしもの時に備えて抜かりないのがスマートなオトコのスタイルである。データベースのご利用は計画的に。 と思ったそこのアナタ！！人生そんなに楽ではありません。 もちろんRDBMSはトランザクションのDurabilityを保証しているので99%の場合はそれでOKだけど、それはCOMMITが成功した場合の話。COMMITは大抵の場合高速な処理であるが、それでも処理にかかる時間はゼロではない。アプリケーションがデータベースサーバにCOMMITを送信してから
シンプルで移行しやすいデータベースシャーディング - クックパッド開発者ブログ
技術部の小野(taiki45)です。クックパッドではこれまで様々なデータベースの負荷対策を行ってきましたが、シャーディングは行われていませんでした。しかし先日クックパッドの認可サーバーが利用している MySQL サーバーの負荷分散のためにクックパッドで初めてのシャーディングを行ったので、Rails アプリケーションでのシャーディングの事例のひとつとしてその際の手法をご紹介したいとおもいます。 構成 Before データベースは1マスター、1ホットスタンバイ、バッチ用の1リードレプリカで構成されています。Read オペレーションのほとんどはキャッシュ層に逃しています。 After データベースの各ロールにつきそれぞれ1台ずつマシンが増えています。 シャーディングが必要になった背景 認可サーバーのアクセストークンの作成・削除時の Write オペレーションが急増し、レコード数自体も急増していて
それでもローカルのMySQLが動かないときしたこと - DRYな備忘録
まずまとめ この時はこれで動きました brewでmysql(他)を削除&再インストール databeseを作る→ mysql_install_db --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql 最終的にはこれ → sudo /usr/local/opt/mysql/bin/mysqld_safe & ログ (´-`).｡ｏO( もういいや、消そう # 消す % sudo brew uninstall mysql # 入れようとする % sudo brew install mysql # ぉこされたからフォーミュラをアップグレードする % sudo brew upgrade mysql # さらにぉこされた # CommandLineToolsが古いとかなんとか # 言われた通りのコマンドを打つ % xco
あわわうぇｂ
MySQLの管理ツールと言えば「phpMyAdmin」が有名で、 私もずっと使ってきたのですが、 Webベースということもあり何かと使いづらい…とずっと思っていました。 クライアントツールが無いものかと探してはいたのですが、 探し方が悪いのかなかなか見つからず。。。 ところが先日、「これ知らないプログラマって損してんなって思う汎用的なツール」というページで いくつかWindowsで使えるフリーのMySQLクライアントが紹介されていたのです！ ずっと探してたの！というわけで、いくつか試してみました。 目次 今回試したクライアントツールは以下の3つです。 MySQL Workbench HeidiSQL 黒猫 SQL Studio Next 1つずつ使用した感想などを書いていきたいと思います！ 1. MySQL Workbench https://www-jp.mysql.com/produc
Sequel Pro
Full MySQL Support Sequel Pro is a fast, easy-to-use Mac database management application for working with MySQL databases. Perfect Web Development Companion Whether you are a Mac Web Developer, Programmer or Software Developer your workflow will be streamlined with a native Mac OS X Application! Flexible Connectivity Sequel Pro gives you direct access to your MySQL Databases on local and remote se
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Connection Pool - ScalikeJDBC
MySQLアンチパターン
そんなトランザクションマネージャで大丈夫か？
Loading...
現場指向のレプリケーション詳説
nmtysh.log
Load Balancing and MySQL Master and Slaves :: The Bakery: Everything CakePHP