MySQLで指定されたカラム名を持つテーブルを検索する - Qiita
select table_name, column_name from information_schema.columns where column_name = '検索したいカラム名' and table_schema = '検索対象のデータベース名'; Register as a new user and use Qiita more conveniently You get articles that match your needsYou can efficiently read back useful informationYou can use dark themeWhat you can do with signing up
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.2.3 識別子の大文字と小文字の区別
MySQL において、データベースはデータディレクトリ内のディレクトリに対応しています。 データベース内の各テーブルも、データベースディレクトリ内の少なくとも 1 つ (ストレージエンジンによってはそれ以上) のファイルに対応しています。 トリガーもファイルに対応しています。 この結果、基になるオペレーティングシステムで大文字と小文字が区別されるかどうかが、データベース名、テーブル名、およびトリガー名で大文字と小文字が区別されるかどうかに影響します。 つまり、このような名前は Windows では大文字と小文字が区別されませんが、ほとんどの種類の Unix では大文字と小文字が区別されます。 特に重要な例外は、Unix ベースであるが、大/小文字を区別しないデフォルトのファイルシステムタイプ (HFS+) を使用する macOS です。 ただし、macOS は UFS ボリュームもサポート
ALTER TABLEを上手に使いこなそう。
テーブル定義を変更したい。インデックスが壊れてしまったので再作成したい。そんな場合はALTER TABLEを使う。ALTER TABLEはテーブル定義を変更するお馴染みのコマンドであるが、その挙動は意外と知られていない。（エキスパートとおぼしき方々からも度々質問を受ける。）そんなわけで、今日はALTER TABLEについて解説しようと思う。 まず結論から言うと、なんとMySQLのALTER TABLEはテーブルのデータを全てコピーし直すのである。なんて無駄なことを！？と思うかも知れないが、テーブル定義（スキーマ）の変更を動的に行うには、ストレージエンジンによるサポートが必要であり、動的なスキーマ変更をサポートしているストレージエンジンはまだ少ないのである。（動的スキーマ変更をサポートしているのはMySQL Clusterぐらいだ。しかも追加だけ。）デフォルトで利用出来るMyISAMはInn
MySQLでALTER TABLE文の進捗状況を確認する - SH2の日記
MySQLでテーブルへのカラム追加やテーブルの再編成を行うには、ALTER TABLE文を使用します。MySQLのALTER TABLE文は、変更後の定義にもとづく作業用テーブルを作成し、変更前のテーブルから作業用テーブルへデータをコピーして、最後に二つのテーブルを入れ替えるという仕組みになっています。テーブルへのインデックス追加についても、現在のところ大半のケースで内部的にALTER TABLE文が実行されています。 ALTER TABLE文の怖いところは、処理がもうすぐ終わるのかどうかが分からないところです。テーブルサイズが1GBを超えるあたりから分単位の時間がかかるようになり、100GBともなると本当に終わるのか？と見ていて不安になります。メンテナンス時間が限られている場合は、作業を中断すべきかどうか難しい判断を迫られることもあります。 実は、というほどではありませんが、ALTER
MySQLのテーブル最適化 - Still Laughin'
PostgreSQL や SQLite では VACUUM 文， MySQL では OPTIMIZE TABLE 構文を用いて データベースのテーブルを最適化することができます。 特にデータストレージにデータベースを使用しているブログシステムでは， スパムコメントやスパムトラックバックを削除したり一つのエントリを何度も編集したりと， どうしてもデータベースが断片化し易い環境にあります。 MySQLは定期的にVACUUMする必要がないというのがウリだったと思うのですが、やはり長年使っているとフラグメントするんですかね？ 基本的に使いっぱなしで何もしていないので、一応やってみました。 /var/db/mysql に optimize.sql という名前で、 USE `（MTのデータベース名）`; OPTIMIZE TABLE `mt_as_ua_cache`; OPTIMIZE TAB
MyISAMでテーブルが巨大すぎるとDELETEできなくなる件（MERGEテーブル解説） - 昼メシ物語
MySQL4.1でMyISAMを使っていて、ふと気づいたら1つのテーブルに4千万件のレコードを挿入してしまいました。 MyISAMで4千万行のテーブルを作るとどうなるかというと、 INSERT -> やや重いけどいける UPDATE -> やや重いけどいける TRUNCATE/DROP -> 一瞬 DELETE -> 破滅 という感じになることが分かりました。 このテーブルには、挿入日を示すカラムがあって、挿入から時間の経った古いレコードを削除したかったんです。 DELETE FROM large_table WHERE created_at > :expire_date この large_table が4千万行あるのですが、このDELETE文を実行したら7日間くらい返ってきませんでしたし、その間ずっと disk busy になったりしてサーバの調子が悪くなりました。 created_at
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL の MERGE テーブルで巨大なテーブルを効率的に運用する