DBにインデックスを追加

正直言って、Laravelのmigration機能は私のLaravelのプロジェクトでは使用したことありません。よく理解していないこともあり、失敗してクライアントのデータベースを空にしてしまうことを考えると悪夢です。とか言ってコマンドラインでSQL文を実行する現状もリスクはそう変わりません。ということで、前回においてmigrationを使用する機会があったので、この際にmigrationの理解を深めたいです。

DBにインデックスを追加

まず、前回においては以下のようなmigrationを作成することで新規のテーブルaddressesを作成しました。

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
 
class CreateAddressesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('addresses', function (Blueprint $table) {
            $table->increments('id');
            $table->integer('user_id')->unsigned();
            $table->string('address');
            $table->timestamps();
        });
    }
 
    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('addresses');
    }
}

そして、以下を実行することで、addressesのテーブルを作成できます。

$ php artisan migrate
Migrating: 2019_01_10_140631_create_addresses_table
Migrated:  2019_01_10_140631_create_addresses_table

しかし、これではusersのテーブルとのjoinにおいてパフォーマンスが良くありません。
例えば、以下のようなクエリを実行するときです。

Psy Shell v0.9.3 (PHP 7.1.14 — cli) by Justin Hileman
>>> User::join('addresses', 'users.id', '=', 'addresses.user_id')->get();

SQL文では以下となります。

mysql> select * from `users` inner join `addresses` on `users`.`id` = `addresses`.`user_id`

しかし、このjoinでは、データベースはマッチするuser_idを探すために毎回addressesのレコードをすべてチェックしなければなりません。レコード数が多くなれば、クエリの実行時間はとても長くなります。

しかし、これは、addresses.user_idにインデックスを追加するだけで簡単に解決できます。

migrationを作成してインデックスを追加してみましょう。

まず、migrationを作成します。

$ php artisan make:migration change_addresses --table=addresses

作成されたファイルを編集します。

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class ChangeAddressesTable extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->index('user_id');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->dropIndex('addresses_user_id_index');
        });
    }
}

これだけです。rollbackのためにdown()も定義することを忘れないように。dropIndex()の引数は、DBの項目名ではなく、間に下線文字を入れて、テーブル名と項目名とindexの文字列をコンバインします（例：addresses_user_id_index）。

次は、このmigrationの反映ですが、その前に–pretendのオプションでどんなSQL文が実行されるかチェックしてみます。

$ php artisan migrate --pretend
ChangeAddressesTable: alter table `addresses` add index `addresses_user_id_index`(`user_id`)

いいですね。思い通りです。

実際にmigrateします。

$ php artisan migrate
Migrating: 2019_01_15_132109_change_addresses_table
Migrated:  2019_01_15_132109_change_addresses_table

住所タイプの導入とユニークインデックスの追加

次は、もう少し複雑なケースを見てみましょう。

現在は、1ユーザー(usersの1レコード）において、複数の住所（addressesのレコード）を紐づけることができますが、住所が会社のものか自宅なのか別荘（夢）なのかわかりません。そこで、その情報を保存するために住所タイプなるtypeという項目を追加します。

migrationを作成します。

$ php artisan make:migration change_addresses2 --table=addresses

作成されたファイルを編集します。

use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;

class ChangeAddresses2Table extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::table('addresses', function (Blueprint $table) {
            // 項目の追加
            $table->string('type')->after('user_id');

            // インデックスを付け直す
            $table->dropIndex('addresses_user_id_index');
            $table->unique(['user_id','type']);
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::table('addresses', function (Blueprint $table) {
            $table->string('type')->after('user_id');                                                                                                                                                              
                                                                                                                                                                                                                   
            $table->dropIndex('addresses_user_id_index');                                                                                                                                                          
            $table->unique(['user_id','type']);  
        });
    }
}

typeの項目の追加の後には、現在のインデックスを削除して新規にuser_idとtypeをコンバインしたインデックスを追加しなおします。そして、1ユーザーに対して住所タイプは同じものを使用できない制限のために、unique()の関数を使用します。

またもや、–pretendでSQL文をチェックします。

$ php artisan migrate --pretend
ChangeAddresses2Table: alter table `addresses` add `type` varchar(191) not null after `user_id`
ChangeAddresses2Table: alter table `addresses` drop index `addresses_user_id_index`
ChangeAddresses2Table: alter table `addresses` add unique `addresses_user_id_type_unique`(`user_id`, `type`)

次は、migrateの実行なのですが、すでにデータがある状態で実行するとレコード重複のエラーが出る可能性あります。とくにすでに１ユーザーに対して複数の住所のレコードがある場合は、それらの項目に新規の項目typeに空が入ってくるからです。

今回は、このエラーを避けるために、migrate:freshを実行します。すべてのテーブルをdropしてから作成したmigrationをすべて実行してくれます。

$ php artisan migrate:fresh
Dropped all tables successfully.
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table
Migrating: 2019_01_10_140631_create_addresses_table
Migrated:  2019_01_10_140631_create_addresses_table
Migrating: 2019_01_15_132109_change_addresses_table
Migrated:  2019_01_15_132109_change_addresses_table
Migrating: 2019_01_18_131940_change_addresses2_table
Migrated:  2019_01_18_131940_change_addresses2_table

しかし、実際のプロダクションではできないことですね。データ皆空になってしまうし。その対応は課題としましょう。

フェイクデータの作成

さて、DBテーブルができたところで、前回のようにフェイクデータの作成をしてみたいです。

今回追加したtypeの項目のために、database/factories/AddressFactory.phpを編集します。

use Faker\Generator as Faker;

$factory->define(App\Address::class, function (Faker $faker) {
    return [
       'type'    => $faker->randomElement(['自宅', '会社']),
       'address' => $faker->address
    ];
});

tinkerで実行してみます。

>>> factory(App\User::class,3)->create()->each(function ($user) { $user->addresses()->save(factory(App\Address::class)->make()); });
...
User::join('addresses', 'users.id', '=', 'addresses.user_id')->get();
=> Illuminate\Database\Eloquent\Collection {#2346
     all: [
       App\User {#2307
         id: 1,
         name: "山本 七夏",
         email: "hirokawa.osamu@example.org",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 1,
         type: "自宅",
         address: "5212837  京都府佐々木市西区近藤町加納9-4-4 コーポ宮沢110号",
       },
       App\User {#2353
         id: 2,
         name: "若松 裕樹",
         email: "tsuda.rika@example.com",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 2,
         type: "自宅",
         address: "4853444  奈良県佐々木市南区鈴木町廣川8-3-9",
       },
       App\User {#2355
         id: 3,
         name: "江古田 裕太",
         email: "ksato@example.org",
         created_at: "2019-01-19 02:33:51",
         updated_at: "2019-01-19 02:33:51",
         user_id: 3,
         type: "会社",
         address: "8386040  愛知県宮沢市中央区井高町加納4-2-10",
       },
     ],
   }

うまくフェイクデータが作成されましたね。

最後に１つ有用なコマンドとして、migrate:status。現在のmigrationのステータスを一覧できます。左の1列目がすべてＹとなっているのは現在あるmigrationがすべて実行された状態です。

$ php artisan migrate:status
+------+------------------------------------------------+
| Ran? | Migration                                      |
+------+------------------------------------------------+
| Y    | 2014_10_12_000000_create_users_table           |
| Y    | 2014_10_12_100000_create_password_resets_table |
| Y    | 2019_01_10_140631_create_addresses_table       |
| Y    | 2019_01_15_132109_change_addresses_table       |
| Y    | 2019_01_18_131940_change_addresses2_table      |
+------+------------------------------------------------+

migrate:rollbackしたなら、すべてNoのＮとなります。

+------+------------------------------------------------+
| Ran? | Migration                                      |
+------+------------------------------------------------+
| N    | 2014_10_12_000000_create_users_table           |
| N    | 2014_10_12_100000_create_password_resets_table |
| N    | 2019_01_10_140631_create_addresses_table       |
| N    | 2019_01_15_132109_change_addresses_table       |
| N    | 2019_01_18_131940_change_addresses2_table      |
+------+------------------------------------------------+