Query performance debuging











up vote
2
down vote

favorite












I have recently installed a new module(paypal express) in Oxid 6.0.x backend.
After installation, the backend menu point "orders", in my backend, is timing out. Cause the query needs too long. I am not able to view orders (which is a CMS vendor resource).



I already tried to debug it with our managed hoster support who doubled our ram to increased mysql buffer size as well as php timouts etc. within the php.ini.



After the hoster php.ini change I still see the query with status "Copying to tmp table" even so the hoster has increased the query buffers etc.



Question:

I am really not sure what the problem is. Does someone have an Idea what else I might try?
I cannot imagine that this one small join needs so much buffer space and time to excecute. Especially since the join to payppaypalpluspayment is the same as to oxv_oxpayments_de which is instant and on the same primary key.



This is the query I see running in processlist

Showing rows 0 - 0 (1 total, Query took 200.9683 seconds.) Has already decreased from about 10 min after the php.ini change



select count(*) from  `oxorder`
LEFT JOIN `oxv_oxpayments_de` AS `payments` on `payments`.oxid=oxorder.oxpaymenttype
LEFT JOIN `oxv_oxpayments_de` AS pluspayments ON pluspayments.oxid = oxorder.oxpaymenttype
LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID
LEFT JOIN payppaypalpluspui ON payppaypalpluspui.OXPAYMENTID = payppaypalpluspayment.OXPAYMENTID
where 1 and ( oxorder.oxfolder = 'ORDERFOLDER_NEW' )


count(*) Result 150000

The problem may be this join, the others are instant results

rows 0 - 0 (1 total, Query took 153.2391 seconds.)



Select count(*) from  `oxorder`

LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID


EXPLAIN



id select_type  table                   type    possible_keys   key         key_len     ref     rows        Extra   
1 SIMPLE oxorder index NULL MAINIDX 10 NULL 146861 Using index
1 SIMPLE payppaypalpluspayment index NULL OXORDERID 32 NULL 2630 Using where; Using index; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ALL NULL NULL NULL NULL 519 Using where


Changed after adding suggested indexes in




oxorder.OXPAYMENTTYPE;
oxorder.oxfolder;
payppaypalpluspui.OXPAYMENTID;
payppaypalpluspayment.OXPAYMENTID;




id  select_type     table                   type    possible_keys   key         key_len ref                                 rows    Extra   
1 SIMPLE oxorder ref OXFOLDER OXFOLDER 98 const 73450 Using index condition
1 SIMPLE payppaypalpluspayment ALL NULL NULL NULL NULL 2634 Using where; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ref OXPAYMENTID OXPAYMENTID 34 payppaypalpluspayment.OXPAYMENTID 1 Using where; Using index


After this count selects the backend is doing the same query with select oxorder.* and one column from payppaypalpluspui (takes about 600 seconds)
The UI has then already timed out. When I delete the last two joins and try it manually on the server the query takes < 1sec



dbs



CREATE TABLE `payppaypalpluspayment` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXORDERID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Order id',
`OXSALEID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment sale id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXSTATUS` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment status',
`OXDATECREATED` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Payment creation date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'Total payment amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'Payment currency',
`OXPAYMENTOBJECT` blob NOT NULL COMMENT 'Serialized payment object',
PRIMARY KEY (`OXID`),
UNIQUE KEY `OXORDERID` (`OXORDERID`),
UNIQUE KEY `OXSALEID` (`OXSALEID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus payment data model'


Rows 3,228 InnoDB utf8_general_ci 11.4 MiB



CREATE TABLE `oxorder` (
`OXID` char(32) NOT NULL COMMENT 'Order id',
`OXSHOPID` int(11) NOT NULL DEFAULT '1' COMMENT 'Shop id (oxshops)',
`OXUSERID` char(32) NOT NULL DEFAULT '' COMMENT 'User id (oxuser)',
`OXORDERDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Order date',
`OXORDERNR` varchar(16) NOT NULL COMMENT 'Order number',
.....
PRIMARY KEY (`OXID`),
KEY `MAINIDX` (`OXSHOPID`,`OXSTORNO`,`OXORDERDATE`),
KEY `OXORDERNR` (`OXORDERNR`)
KEY `OXPAYMENTTYPE` (`OXPAYMENTTYPE`), <<<< added this index
KEY `OXFOLDER` (`OXFOLDER`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Shop orders information'


149,068 InnoDB utf8_general_ci 258.1 MiB



CREATE TABLE `payppaypalpluspui` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXREFERENCENUMBER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI reference_number',
`OXBANKNAME` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction bank name',
`OXACCOUNTHOLDER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction account holder',
`OXIBAN` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction IBAN',
`OXBIC` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction BIC',
`OXDUEDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'PayPal Plus PuI due date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'PayPal Plus PuI Total invoice amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI invoice currency',
`OXPUIOBJECT` text NOT NULL COMMENT 'JSON representation of the payment instructions',
PRIMARY KEY (`OXID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus Pay upon Invoice data model'


Rows 655 InnoDB utf8_general_ci 1.5 MiB



innodb buffer pool = 8 GiB

RAM 10 GiB










share|improve this question
























  • Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
    – jeroen
    Nov 8 at 10:08












  • I added the index, which did not change the request time
    – veritaS
    Nov 8 at 10:14










  • payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
    – Sergiu Paraschiv
    Nov 8 at 10:17










  • yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
    – veritaS
    Nov 8 at 10:17










  • That's expected seeing that a full scan took 600 seconds :)
    – Sergiu Paraschiv
    Nov 8 at 10:21















up vote
2
down vote

favorite












I have recently installed a new module(paypal express) in Oxid 6.0.x backend.
After installation, the backend menu point "orders", in my backend, is timing out. Cause the query needs too long. I am not able to view orders (which is a CMS vendor resource).



I already tried to debug it with our managed hoster support who doubled our ram to increased mysql buffer size as well as php timouts etc. within the php.ini.



After the hoster php.ini change I still see the query with status "Copying to tmp table" even so the hoster has increased the query buffers etc.



Question:

I am really not sure what the problem is. Does someone have an Idea what else I might try?
I cannot imagine that this one small join needs so much buffer space and time to excecute. Especially since the join to payppaypalpluspayment is the same as to oxv_oxpayments_de which is instant and on the same primary key.



This is the query I see running in processlist

Showing rows 0 - 0 (1 total, Query took 200.9683 seconds.) Has already decreased from about 10 min after the php.ini change



select count(*) from  `oxorder`
LEFT JOIN `oxv_oxpayments_de` AS `payments` on `payments`.oxid=oxorder.oxpaymenttype
LEFT JOIN `oxv_oxpayments_de` AS pluspayments ON pluspayments.oxid = oxorder.oxpaymenttype
LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID
LEFT JOIN payppaypalpluspui ON payppaypalpluspui.OXPAYMENTID = payppaypalpluspayment.OXPAYMENTID
where 1 and ( oxorder.oxfolder = 'ORDERFOLDER_NEW' )


count(*) Result 150000

The problem may be this join, the others are instant results

rows 0 - 0 (1 total, Query took 153.2391 seconds.)



Select count(*) from  `oxorder`

LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID


EXPLAIN



id select_type  table                   type    possible_keys   key         key_len     ref     rows        Extra   
1 SIMPLE oxorder index NULL MAINIDX 10 NULL 146861 Using index
1 SIMPLE payppaypalpluspayment index NULL OXORDERID 32 NULL 2630 Using where; Using index; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ALL NULL NULL NULL NULL 519 Using where


Changed after adding suggested indexes in




oxorder.OXPAYMENTTYPE;
oxorder.oxfolder;
payppaypalpluspui.OXPAYMENTID;
payppaypalpluspayment.OXPAYMENTID;




id  select_type     table                   type    possible_keys   key         key_len ref                                 rows    Extra   
1 SIMPLE oxorder ref OXFOLDER OXFOLDER 98 const 73450 Using index condition
1 SIMPLE payppaypalpluspayment ALL NULL NULL NULL NULL 2634 Using where; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ref OXPAYMENTID OXPAYMENTID 34 payppaypalpluspayment.OXPAYMENTID 1 Using where; Using index


After this count selects the backend is doing the same query with select oxorder.* and one column from payppaypalpluspui (takes about 600 seconds)
The UI has then already timed out. When I delete the last two joins and try it manually on the server the query takes < 1sec



dbs



CREATE TABLE `payppaypalpluspayment` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXORDERID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Order id',
`OXSALEID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment sale id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXSTATUS` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment status',
`OXDATECREATED` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Payment creation date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'Total payment amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'Payment currency',
`OXPAYMENTOBJECT` blob NOT NULL COMMENT 'Serialized payment object',
PRIMARY KEY (`OXID`),
UNIQUE KEY `OXORDERID` (`OXORDERID`),
UNIQUE KEY `OXSALEID` (`OXSALEID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus payment data model'


Rows 3,228 InnoDB utf8_general_ci 11.4 MiB



CREATE TABLE `oxorder` (
`OXID` char(32) NOT NULL COMMENT 'Order id',
`OXSHOPID` int(11) NOT NULL DEFAULT '1' COMMENT 'Shop id (oxshops)',
`OXUSERID` char(32) NOT NULL DEFAULT '' COMMENT 'User id (oxuser)',
`OXORDERDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Order date',
`OXORDERNR` varchar(16) NOT NULL COMMENT 'Order number',
.....
PRIMARY KEY (`OXID`),
KEY `MAINIDX` (`OXSHOPID`,`OXSTORNO`,`OXORDERDATE`),
KEY `OXORDERNR` (`OXORDERNR`)
KEY `OXPAYMENTTYPE` (`OXPAYMENTTYPE`), <<<< added this index
KEY `OXFOLDER` (`OXFOLDER`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Shop orders information'


149,068 InnoDB utf8_general_ci 258.1 MiB



CREATE TABLE `payppaypalpluspui` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXREFERENCENUMBER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI reference_number',
`OXBANKNAME` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction bank name',
`OXACCOUNTHOLDER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction account holder',
`OXIBAN` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction IBAN',
`OXBIC` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction BIC',
`OXDUEDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'PayPal Plus PuI due date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'PayPal Plus PuI Total invoice amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI invoice currency',
`OXPUIOBJECT` text NOT NULL COMMENT 'JSON representation of the payment instructions',
PRIMARY KEY (`OXID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus Pay upon Invoice data model'


Rows 655 InnoDB utf8_general_ci 1.5 MiB



innodb buffer pool = 8 GiB

RAM 10 GiB










share|improve this question
























  • Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
    – jeroen
    Nov 8 at 10:08












  • I added the index, which did not change the request time
    – veritaS
    Nov 8 at 10:14










  • payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
    – Sergiu Paraschiv
    Nov 8 at 10:17










  • yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
    – veritaS
    Nov 8 at 10:17










  • That's expected seeing that a full scan took 600 seconds :)
    – Sergiu Paraschiv
    Nov 8 at 10:21













up vote
2
down vote

favorite









up vote
2
down vote

favorite











I have recently installed a new module(paypal express) in Oxid 6.0.x backend.
After installation, the backend menu point "orders", in my backend, is timing out. Cause the query needs too long. I am not able to view orders (which is a CMS vendor resource).



I already tried to debug it with our managed hoster support who doubled our ram to increased mysql buffer size as well as php timouts etc. within the php.ini.



After the hoster php.ini change I still see the query with status "Copying to tmp table" even so the hoster has increased the query buffers etc.



Question:

I am really not sure what the problem is. Does someone have an Idea what else I might try?
I cannot imagine that this one small join needs so much buffer space and time to excecute. Especially since the join to payppaypalpluspayment is the same as to oxv_oxpayments_de which is instant and on the same primary key.



This is the query I see running in processlist

Showing rows 0 - 0 (1 total, Query took 200.9683 seconds.) Has already decreased from about 10 min after the php.ini change



select count(*) from  `oxorder`
LEFT JOIN `oxv_oxpayments_de` AS `payments` on `payments`.oxid=oxorder.oxpaymenttype
LEFT JOIN `oxv_oxpayments_de` AS pluspayments ON pluspayments.oxid = oxorder.oxpaymenttype
LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID
LEFT JOIN payppaypalpluspui ON payppaypalpluspui.OXPAYMENTID = payppaypalpluspayment.OXPAYMENTID
where 1 and ( oxorder.oxfolder = 'ORDERFOLDER_NEW' )


count(*) Result 150000

The problem may be this join, the others are instant results

rows 0 - 0 (1 total, Query took 153.2391 seconds.)



Select count(*) from  `oxorder`

LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID


EXPLAIN



id select_type  table                   type    possible_keys   key         key_len     ref     rows        Extra   
1 SIMPLE oxorder index NULL MAINIDX 10 NULL 146861 Using index
1 SIMPLE payppaypalpluspayment index NULL OXORDERID 32 NULL 2630 Using where; Using index; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ALL NULL NULL NULL NULL 519 Using where


Changed after adding suggested indexes in




oxorder.OXPAYMENTTYPE;
oxorder.oxfolder;
payppaypalpluspui.OXPAYMENTID;
payppaypalpluspayment.OXPAYMENTID;




id  select_type     table                   type    possible_keys   key         key_len ref                                 rows    Extra   
1 SIMPLE oxorder ref OXFOLDER OXFOLDER 98 const 73450 Using index condition
1 SIMPLE payppaypalpluspayment ALL NULL NULL NULL NULL 2634 Using where; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ref OXPAYMENTID OXPAYMENTID 34 payppaypalpluspayment.OXPAYMENTID 1 Using where; Using index


After this count selects the backend is doing the same query with select oxorder.* and one column from payppaypalpluspui (takes about 600 seconds)
The UI has then already timed out. When I delete the last two joins and try it manually on the server the query takes < 1sec



dbs



CREATE TABLE `payppaypalpluspayment` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXORDERID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Order id',
`OXSALEID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment sale id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXSTATUS` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment status',
`OXDATECREATED` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Payment creation date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'Total payment amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'Payment currency',
`OXPAYMENTOBJECT` blob NOT NULL COMMENT 'Serialized payment object',
PRIMARY KEY (`OXID`),
UNIQUE KEY `OXORDERID` (`OXORDERID`),
UNIQUE KEY `OXSALEID` (`OXSALEID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus payment data model'


Rows 3,228 InnoDB utf8_general_ci 11.4 MiB



CREATE TABLE `oxorder` (
`OXID` char(32) NOT NULL COMMENT 'Order id',
`OXSHOPID` int(11) NOT NULL DEFAULT '1' COMMENT 'Shop id (oxshops)',
`OXUSERID` char(32) NOT NULL DEFAULT '' COMMENT 'User id (oxuser)',
`OXORDERDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Order date',
`OXORDERNR` varchar(16) NOT NULL COMMENT 'Order number',
.....
PRIMARY KEY (`OXID`),
KEY `MAINIDX` (`OXSHOPID`,`OXSTORNO`,`OXORDERDATE`),
KEY `OXORDERNR` (`OXORDERNR`)
KEY `OXPAYMENTTYPE` (`OXPAYMENTTYPE`), <<<< added this index
KEY `OXFOLDER` (`OXFOLDER`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Shop orders information'


149,068 InnoDB utf8_general_ci 258.1 MiB



CREATE TABLE `payppaypalpluspui` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXREFERENCENUMBER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI reference_number',
`OXBANKNAME` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction bank name',
`OXACCOUNTHOLDER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction account holder',
`OXIBAN` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction IBAN',
`OXBIC` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction BIC',
`OXDUEDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'PayPal Plus PuI due date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'PayPal Plus PuI Total invoice amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI invoice currency',
`OXPUIOBJECT` text NOT NULL COMMENT 'JSON representation of the payment instructions',
PRIMARY KEY (`OXID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus Pay upon Invoice data model'


Rows 655 InnoDB utf8_general_ci 1.5 MiB



innodb buffer pool = 8 GiB

RAM 10 GiB










share|improve this question















I have recently installed a new module(paypal express) in Oxid 6.0.x backend.
After installation, the backend menu point "orders", in my backend, is timing out. Cause the query needs too long. I am not able to view orders (which is a CMS vendor resource).



I already tried to debug it with our managed hoster support who doubled our ram to increased mysql buffer size as well as php timouts etc. within the php.ini.



After the hoster php.ini change I still see the query with status "Copying to tmp table" even so the hoster has increased the query buffers etc.



Question:

I am really not sure what the problem is. Does someone have an Idea what else I might try?
I cannot imagine that this one small join needs so much buffer space and time to excecute. Especially since the join to payppaypalpluspayment is the same as to oxv_oxpayments_de which is instant and on the same primary key.



This is the query I see running in processlist

Showing rows 0 - 0 (1 total, Query took 200.9683 seconds.) Has already decreased from about 10 min after the php.ini change



select count(*) from  `oxorder`
LEFT JOIN `oxv_oxpayments_de` AS `payments` on `payments`.oxid=oxorder.oxpaymenttype
LEFT JOIN `oxv_oxpayments_de` AS pluspayments ON pluspayments.oxid = oxorder.oxpaymenttype
LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID
LEFT JOIN payppaypalpluspui ON payppaypalpluspui.OXPAYMENTID = payppaypalpluspayment.OXPAYMENTID
where 1 and ( oxorder.oxfolder = 'ORDERFOLDER_NEW' )


count(*) Result 150000

The problem may be this join, the others are instant results

rows 0 - 0 (1 total, Query took 153.2391 seconds.)



Select count(*) from  `oxorder`

LEFT JOIN payppaypalpluspayment ON payppaypalpluspayment.OXORDERID = oxorder.OXID


EXPLAIN



id select_type  table                   type    possible_keys   key         key_len     ref     rows        Extra   
1 SIMPLE oxorder index NULL MAINIDX 10 NULL 146861 Using index
1 SIMPLE payppaypalpluspayment index NULL OXORDERID 32 NULL 2630 Using where; Using index; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ALL NULL NULL NULL NULL 519 Using where


Changed after adding suggested indexes in




oxorder.OXPAYMENTTYPE;
oxorder.oxfolder;
payppaypalpluspui.OXPAYMENTID;
payppaypalpluspayment.OXPAYMENTID;




id  select_type     table                   type    possible_keys   key         key_len ref                                 rows    Extra   
1 SIMPLE oxorder ref OXFOLDER OXFOLDER 98 const 73450 Using index condition
1 SIMPLE payppaypalpluspayment ALL NULL NULL NULL NULL 2634 Using where; Using join buffer (flat, BNL join)
1 SIMPLE payppaypalpluspui ref OXPAYMENTID OXPAYMENTID 34 payppaypalpluspayment.OXPAYMENTID 1 Using where; Using index


After this count selects the backend is doing the same query with select oxorder.* and one column from payppaypalpluspui (takes about 600 seconds)
The UI has then already timed out. When I delete the last two joins and try it manually on the server the query takes < 1sec



dbs



CREATE TABLE `payppaypalpluspayment` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXORDERID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Order id',
`OXSALEID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment sale id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXSTATUS` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment status',
`OXDATECREATED` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Payment creation date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'Total payment amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'Payment currency',
`OXPAYMENTOBJECT` blob NOT NULL COMMENT 'Serialized payment object',
PRIMARY KEY (`OXID`),
UNIQUE KEY `OXORDERID` (`OXORDERID`),
UNIQUE KEY `OXSALEID` (`OXSALEID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus payment data model'


Rows 3,228 InnoDB utf8_general_ci 11.4 MiB



CREATE TABLE `oxorder` (
`OXID` char(32) NOT NULL COMMENT 'Order id',
`OXSHOPID` int(11) NOT NULL DEFAULT '1' COMMENT 'Shop id (oxshops)',
`OXUSERID` char(32) NOT NULL DEFAULT '' COMMENT 'User id (oxuser)',
`OXORDERDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'Order date',
`OXORDERNR` varchar(16) NOT NULL COMMENT 'Order number',
.....
PRIMARY KEY (`OXID`),
KEY `MAINIDX` (`OXSHOPID`,`OXSTORNO`,`OXORDERDATE`),
KEY `OXORDERNR` (`OXORDERNR`)
KEY `OXPAYMENTTYPE` (`OXPAYMENTTYPE`), <<<< added this index
KEY `OXFOLDER` (`OXFOLDER`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='Shop orders information'


149,068 InnoDB utf8_general_ci 258.1 MiB



CREATE TABLE `payppaypalpluspui` (
`OXID` char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL COMMENT 'Payment oxid id',
`OXPAYMENTID` varchar(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT '' COMMENT 'PayPal Plus payment id',
`OXREFERENCENUMBER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI reference_number',
`OXBANKNAME` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction bank name',
`OXACCOUNTHOLDER` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction account holder',
`OXIBAN` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction IBAN',
`OXBIC` varchar(255) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI banking instruction BIC',
`OXDUEDATE` datetime NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'PayPal Plus PuI due date',
`OXTOTAL` double NOT NULL DEFAULT '0' COMMENT 'PayPal Plus PuI Total invoice amount',
`OXCURRENCY` varchar(32) NOT NULL DEFAULT '' COMMENT 'PayPal Plus PuI invoice currency',
`OXPUIOBJECT` text NOT NULL COMMENT 'JSON representation of the payment instructions',
PRIMARY KEY (`OXID`)
KEY `OXPAYMENTID` (`OXPAYMENTID`) <<<< added this index
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='PayPal Plus Pay upon Invoice data model'


Rows 655 InnoDB utf8_general_ci 1.5 MiB



innodb buffer pool = 8 GiB

RAM 10 GiB







php mysql database-performance






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 9 at 7:35

























asked Nov 8 at 10:00









veritaS

317314




317314












  • Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
    – jeroen
    Nov 8 at 10:08












  • I added the index, which did not change the request time
    – veritaS
    Nov 8 at 10:14










  • payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
    – Sergiu Paraschiv
    Nov 8 at 10:17










  • yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
    – veritaS
    Nov 8 at 10:17










  • That's expected seeing that a full scan took 600 seconds :)
    – Sergiu Paraschiv
    Nov 8 at 10:21


















  • Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
    – jeroen
    Nov 8 at 10:08












  • I added the index, which did not change the request time
    – veritaS
    Nov 8 at 10:14










  • payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
    – Sergiu Paraschiv
    Nov 8 at 10:17










  • yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
    – veritaS
    Nov 8 at 10:17










  • That's expected seeing that a full scan took 600 seconds :)
    – Sergiu Paraschiv
    Nov 8 at 10:21
















Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
– jeroen
Nov 8 at 10:08






Adding an index on oxorder.oxpaymenttype wouldn't hurt. On any of the fields you use to join (or sort...) on.
– jeroen
Nov 8 at 10:08














I added the index, which did not change the request time
– veritaS
Nov 8 at 10:14




I added the index, which did not change the request time
– veritaS
Nov 8 at 10:14












payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
– Sergiu Paraschiv
Nov 8 at 10:17




payppaypalpluspui type: ALL, so no index is used, meaning it does a full table scan. So you need an index on payppaypalpluspui.OXPAYMENTID.
– Sergiu Paraschiv
Nov 8 at 10:17












yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
– veritaS
Nov 8 at 10:17




yes, currently adding payppaypalpluspui.OXPAYMENTID index... this seems to be taking some time
– veritaS
Nov 8 at 10:17












That's expected seeing that a full scan took 600 seconds :)
– Sergiu Paraschiv
Nov 8 at 10:21




That's expected seeing that a full scan took 600 seconds :)
– Sergiu Paraschiv
Nov 8 at 10:21












2 Answers
2






active

oldest

votes

















up vote
3
down vote













Your problem is that you are comparing columns encoded in different character sets, latin1 and utf8. In such cases, index may not be used for key look-ups. You should make sure to use the same character set for all your key columns.






share|improve this answer




























    up vote
    0
    down vote













    Edit: originally I thought that the LEFT Join's were not relevant, but in theory they can inflate the count as pointed out by the comments.



    For this count query. All of the LEFT JOIN's seem irrelevant, since the joined do not seem to contain more rows than the left table, and you retrieve only the count, not the data from those. I would remove all of them (if that would be possible, but I now understand that is not the case)



    For the oxorder.* query. Do not include joins that you don't use. Also you think of changing the primary key if you always access the joined table in a one on one situation






    share|improve this answer























    • these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
      – veritaS
      Nov 8 at 11:49










    • Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
      – Ben Ootjers
      Nov 8 at 11:53










    • has no effect at all
      – veritaS
      Nov 8 at 12:16










    • LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
      – Rick James
      Nov 9 at 0:35











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














     

    draft saved


    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53205345%2fquery-performance-debuging%23new-answer', 'question_page');
    }
    );

    Post as a guest
































    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote













    Your problem is that you are comparing columns encoded in different character sets, latin1 and utf8. In such cases, index may not be used for key look-ups. You should make sure to use the same character set for all your key columns.






    share|improve this answer

























      up vote
      3
      down vote













      Your problem is that you are comparing columns encoded in different character sets, latin1 and utf8. In such cases, index may not be used for key look-ups. You should make sure to use the same character set for all your key columns.






      share|improve this answer























        up vote
        3
        down vote










        up vote
        3
        down vote









        Your problem is that you are comparing columns encoded in different character sets, latin1 and utf8. In such cases, index may not be used for key look-ups. You should make sure to use the same character set for all your key columns.






        share|improve this answer












        Your problem is that you are comparing columns encoded in different character sets, latin1 and utf8. In such cases, index may not be used for key look-ups. You should make sure to use the same character set for all your key columns.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 8 at 15:22









        oysteing

        77836




        77836
























            up vote
            0
            down vote













            Edit: originally I thought that the LEFT Join's were not relevant, but in theory they can inflate the count as pointed out by the comments.



            For this count query. All of the LEFT JOIN's seem irrelevant, since the joined do not seem to contain more rows than the left table, and you retrieve only the count, not the data from those. I would remove all of them (if that would be possible, but I now understand that is not the case)



            For the oxorder.* query. Do not include joins that you don't use. Also you think of changing the primary key if you always access the joined table in a one on one situation






            share|improve this answer























            • these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
              – veritaS
              Nov 8 at 11:49










            • Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
              – Ben Ootjers
              Nov 8 at 11:53










            • has no effect at all
              – veritaS
              Nov 8 at 12:16










            • LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
              – Rick James
              Nov 9 at 0:35















            up vote
            0
            down vote













            Edit: originally I thought that the LEFT Join's were not relevant, but in theory they can inflate the count as pointed out by the comments.



            For this count query. All of the LEFT JOIN's seem irrelevant, since the joined do not seem to contain more rows than the left table, and you retrieve only the count, not the data from those. I would remove all of them (if that would be possible, but I now understand that is not the case)



            For the oxorder.* query. Do not include joins that you don't use. Also you think of changing the primary key if you always access the joined table in a one on one situation






            share|improve this answer























            • these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
              – veritaS
              Nov 8 at 11:49










            • Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
              – Ben Ootjers
              Nov 8 at 11:53










            • has no effect at all
              – veritaS
              Nov 8 at 12:16










            • LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
              – Rick James
              Nov 9 at 0:35













            up vote
            0
            down vote










            up vote
            0
            down vote









            Edit: originally I thought that the LEFT Join's were not relevant, but in theory they can inflate the count as pointed out by the comments.



            For this count query. All of the LEFT JOIN's seem irrelevant, since the joined do not seem to contain more rows than the left table, and you retrieve only the count, not the data from those. I would remove all of them (if that would be possible, but I now understand that is not the case)



            For the oxorder.* query. Do not include joins that you don't use. Also you think of changing the primary key if you always access the joined table in a one on one situation






            share|improve this answer














            Edit: originally I thought that the LEFT Join's were not relevant, but in theory they can inflate the count as pointed out by the comments.



            For this count query. All of the LEFT JOIN's seem irrelevant, since the joined do not seem to contain more rows than the left table, and you retrieve only the count, not the data from those. I would remove all of them (if that would be possible, but I now understand that is not the case)



            For the oxorder.* query. Do not include joins that you don't use. Also you think of changing the primary key if you always access the joined table in a one on one situation







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 9 at 7:35

























            answered Nov 8 at 11:43









            Ben Ootjers

            586




            586












            • these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
              – veritaS
              Nov 8 at 11:49










            • Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
              – Ben Ootjers
              Nov 8 at 11:53










            • has no effect at all
              – veritaS
              Nov 8 at 12:16










            • LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
              – Rick James
              Nov 9 at 0:35


















            • these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
              – veritaS
              Nov 8 at 11:49










            • Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
              – Ben Ootjers
              Nov 8 at 11:53










            • has no effect at all
              – veritaS
              Nov 8 at 12:16










            • LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
              – Rick James
              Nov 9 at 0:35
















            these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
            – veritaS
            Nov 8 at 11:49




            these are not my querys, but they are vendor given (from the CMS and the isntalled modules). I could change them, but only with big effort in that I write a new module which overwrites these queries, which might get into problems later when installing other modules which would add to this. So I am trying to solve this beforehand by checking why this would take so long anyways.
            – veritaS
            Nov 8 at 11:49












            Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
            – Ben Ootjers
            Nov 8 at 11:53




            Understood. So what about changing the primary for table payppaypalpluspayment to column oxorderid?
            – Ben Ootjers
            Nov 8 at 11:53












            has no effect at all
            – veritaS
            Nov 8 at 12:16




            has no effect at all
            – veritaS
            Nov 8 at 12:16












            LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
            – Rick James
            Nov 9 at 0:35




            LEFT JOIN can inflate the count if multiple rows occur on the 'right'.
            – Rick James
            Nov 9 at 0:35


















             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53205345%2fquery-performance-debuging%23new-answer', 'question_page');
            }
            );

            Post as a guest




















































































            Popular posts from this blog

            Schultheiß

            Verwaltungsgliederung Dänemarks

            Liste der Kulturdenkmale in Wilsdruff