2017-04-12 4 views
0

マイグレーションテーブルから通常のテーブルに値をコピーしようとしているテーブルが2つあります。それはしばらく時間がかかるようです。 (43Kレコードの10分)テーブル間の値をコピーするためのmysqlのスピードアップの更新ステートメント

UPDATE phppos_sales_items,phppos_sales_items_migrate 
SET 
    phppos_sales_items.subtotal = phppos_sales_items_migrate.subtotal, 
    phppos_sales_items.tax = phppos_sales_items_migrate.tax, 
    phppos_sales_items.total = phppos_sales_items_migrate.total, 
    phppos_sales_items.profit = phppos_sales_items_migrate.profit 

WHERE 
phppos_sales_items.sale_id = phppos_sales_items_migrate.sale_id and   
phppos_sales_items.line = phppos_sales_items_migrate.line and  
phppos_sales_items.item_id = phppos_sales_items_migrate.item_id; 

移行表

CREATE TABLE `phppos_sales_items_migrate` (
    `sale_id` int(10) NOT NULL DEFAULT '0', 
    `item_id` int(10) NOT NULL DEFAULT '0', 
    `line` int(11) NOT NULL DEFAULT '0', 
    `subtotal` decimal(23,10) DEFAULT NULL, 
    `total` decimal(23,10) DEFAULT NULL, 
    `tax` decimal(23,10) DEFAULT NULL, 
    `profit` decimal(23,10) DEFAULT NULL 
) ENGINE=InnoDB DEFAULT CHARSET=utf8; 

sales_items

CREATE TABLE `phppos_sales_items` (
    `sale_id` int(10) NOT NULL DEFAULT '0', 
    `item_id` int(10) NOT NULL DEFAULT '0', 
    `rule_id` int(10) DEFAULT NULL, 
    `rule_discount` decimal(23,10) DEFAULT NULL, 
    `description` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `serialnumber` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `line` int(11) NOT NULL DEFAULT '0', 
    `quantity_purchased` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    `item_cost_price` decimal(23,10) NOT NULL, 
    `item_unit_price` decimal(23,10) NOT NULL, 
    `regular_item_unit_price_at_time_of_sale` decimal(23,10) DEFAULT NULL, 
    `discount_percent` decimal(15,3) NOT NULL DEFAULT '0.000', 
    `commission` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    `subtotal` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    `tax` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    `total` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    `profit` decimal(23,10) NOT NULL DEFAULT '0.0000000000', 
    PRIMARY KEY (`sale_id`,`item_id`,`line`), 
    KEY `item_id` (`item_id`), 
    KEY `phppos_sales_items_ibfk_3` (`rule_id`), 
    CONSTRAINT `phppos_sales_items_ibfk_1` FOREIGN KEY (`item_id`) REFERENCES `phppos_items` (`item_id`), 
    CONSTRAINT `phppos_sales_items_ibfk_2` FOREIGN KEY (`sale_id`) REFERENCES `phppos_sales` (`sale_id`), 
    CONSTRAINT `phppos_sales_items_ibfk_3` FOREIGN KEY (`rule_id`) REFERENCES `phppos_price_rules` (`id`) 
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 

これをスピードアップする方法はありますか?

答えて

0

私の意見では、ターゲットテーブルにインデックスを追加することは試してみる価値があります。

二つの表は、あなたが(sale_iditem_idline)の列に対してphppos_sales_items_migrateテーブルにインデックスを追加するには、より良い、それをマージするための3つの列があります比較しているので。

グッドラック

PS。 FYIでは、テーブルにインデックスを追加すると、更新と挿入のコストがかかるため、比較カラムに最小化されます。

1

decimal(23,10)は、特にquantity_purchasedのような積分値の場合には過剰です。データ型を縮小すると、速度を上げるのに役立ちます。

JOIN ... ON ...構文の「マルチテーブル更新」を使用してください。

はMySQLの新しい十分なバージョンを持っている場合は、また新しい行がmigrateであるEXPLAIN UPDATE ...

任意のチャンスを提供?さんは

EXPLAIN 
SELECT * FROM phppos_sales_items   AS i 
     JOIN phppos_sales_items_migrate AS m 
     ON i.sale_id = m.sale_id 
     and i.line = m.line 
     and i.item_id = m.item_id; 

からの出力を見てみましょうかもしそうなら、INSERT ... ON DUPLICATE KEY UPDATE ...は必要ないでしょうか?

43K行のテーブルは?他のテーブルにはどれくらいの数がありますか?

関連する問題