Slow query with NULL IS NULL OR condition syntax using Mysql 5.7











up vote
0
down vote

favorite












I'm getting some strange timing values from Mysql running a "simple" query.



This is the DDL of the table:



CREATE TABLE `frame` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`createdBy` varchar(255) DEFAULT NULL,
`createdDate` datetime(6) NOT NULL,
`lastModifiedBy` varchar(255) DEFAULT NULL,
`lastModifiedDate` datetime(6) DEFAULT NULL,
`sid` varchar(36) NOT NULL,
`version` bigint(20) NOT NULL,
`brand` varchar(255) DEFAULT NULL,
`category` varchar(255) DEFAULT NULL,
`colorCode` varchar(255) DEFAULT NULL,
`colorDescription` varchar(255) DEFAULT NULL,
`description` longtext,
`imageUrl` varchar(255) DEFAULT NULL,
`lastPurchase` datetime(6) DEFAULT NULL,
`lastPurchasePrice` decimal(19,2) DEFAULT NULL,
`lastSell` datetime(6) DEFAULT NULL,
`lastSellPrice` decimal(19,2) DEFAULT NULL,
`line` varchar(255) DEFAULT NULL,
`manufacturer` varchar(255) DEFAULT NULL,
`manufacturerCode` varchar(255) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`preset` bit(1) NOT NULL DEFAULT b'0',
`purchasePrice` decimal(19,2) DEFAULT NULL,
`salesPrice` decimal(19,2) DEFAULT NULL,
`sku` varchar(255) NOT NULL,
`stock` bit(1) NOT NULL DEFAULT b'1',
`thumbUrl` varchar(255) DEFAULT NULL,
`upc` varchar(255) DEFAULT NULL,
`arm` int(11) DEFAULT NULL,
`bridge` int(11) DEFAULT NULL,
`caliber` int(11) DEFAULT NULL,
`gender` varchar(255) DEFAULT NULL,
`lensColor` varchar(255) DEFAULT NULL,
`material` varchar(255) DEFAULT NULL,
`model` varchar(255) NOT NULL,
`sphere` decimal(10,2) DEFAULT NULL,
`type` varchar(255) NOT NULL,
`taxRate_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `UK_k7s4esovkoacsc264bcjrre13` (`sid`),
UNIQUE KEY `UK_ajh6mr6a6qg6mgy8t9nevdym1` (`sku`),
UNIQUE KEY `UK_boqikmg9o89j8q0o5ujkj33b3` (`upc`),
KEY `idx_manufacturer` (`manufacturer`),
KEY `idx_brand` (`brand`),
KEY `idx_line` (`line`),
KEY `idx_colorcode` (`colorCode`),
KEY `idx_preset` (`preset`),
KEY `idx_manufacturer_model_color_caliber` (`manufacturer`,`model`,`colorCode`,`caliber`),
KEY `FK1nau29fd70s1nq905dgs6ft85` (`taxRate_id`),
CONSTRAINT `FK1nau29fd70s1nq905dgs6ft85` FOREIGN KEY (`taxRate_id`) REFERENCES `taxrate` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=392179 DEFAULT CHARSET=utf8;


The query is created programatically from my application. The "strange" syntax (NULL IS NULL OR condition) is very convenient to me in order to make more compact my code and removing the need to create a different query based on the numbers of parameters.



For who understand how Hibernate HQL and JPA works, this is the query:



enter image description here



This query is generated when the user is not setting any filter, so all parameters in my condition are null and this is how the query comes out.



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_ 
WHERE (NULL IS NULL OR NULL LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturer` LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturerCode`=NULL OR frame0_.`sku`=NULL OR frame0_.`upc`=NULL OR frame0_.`line` LIKE CONCAT('%', NULL, '%') OR frame0_.`model` LIKE CONCAT('%', NULL, '%')) AND (NULL IS NULL OR frame0_.`manufacturer`=NULL) AND (NULL IS NULL OR frame0_.`line`=NULL) AND (NULL IS NULL OR frame0_.`caliber`=NULL) AND (NULL IS NULL OR frame0_.`type`=NULL) AND (NULL IS NULL OR frame0_.`material`=NULL) AND (NULL IS NULL OR frame0_.`model`=NULL) AND (NULL IS NULL OR frame0_.`colorCode`=NULL)


The query takes about 0.105s on a table of 137548 rows.
The EXPLAIN of the previous query returns:



id  select_type table   partitions  type    possible_keys   key key_len ref rows     filtered   Extra
1 SIMPLE frame0_ N ALL N N N N 137548 100.00 N


The previous query is identical to this one:



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_


This query takes just 0.05s for the same result in the same table.



Why for Mysql they are different and the first is taking so much time? Is there a way to improve performance of the first query keeping the syntax "NULL IS NULL or condition"?










share|improve this question




















  • 1




    The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
    – Ryan Wilson
    Nov 19 at 20:40










  • I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
    – drenda
    Nov 19 at 21:02










  • No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
    – Ryan Wilson
    Nov 19 at 21:08










  • For "re-work your end of things" do you mean build the query based on which filters the user selects?
    – drenda
    Nov 19 at 21:10










  • I suppose so, but you said your current query already takes care of that?
    – Ryan Wilson
    Nov 19 at 21:12















up vote
0
down vote

favorite












I'm getting some strange timing values from Mysql running a "simple" query.



This is the DDL of the table:



CREATE TABLE `frame` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`createdBy` varchar(255) DEFAULT NULL,
`createdDate` datetime(6) NOT NULL,
`lastModifiedBy` varchar(255) DEFAULT NULL,
`lastModifiedDate` datetime(6) DEFAULT NULL,
`sid` varchar(36) NOT NULL,
`version` bigint(20) NOT NULL,
`brand` varchar(255) DEFAULT NULL,
`category` varchar(255) DEFAULT NULL,
`colorCode` varchar(255) DEFAULT NULL,
`colorDescription` varchar(255) DEFAULT NULL,
`description` longtext,
`imageUrl` varchar(255) DEFAULT NULL,
`lastPurchase` datetime(6) DEFAULT NULL,
`lastPurchasePrice` decimal(19,2) DEFAULT NULL,
`lastSell` datetime(6) DEFAULT NULL,
`lastSellPrice` decimal(19,2) DEFAULT NULL,
`line` varchar(255) DEFAULT NULL,
`manufacturer` varchar(255) DEFAULT NULL,
`manufacturerCode` varchar(255) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`preset` bit(1) NOT NULL DEFAULT b'0',
`purchasePrice` decimal(19,2) DEFAULT NULL,
`salesPrice` decimal(19,2) DEFAULT NULL,
`sku` varchar(255) NOT NULL,
`stock` bit(1) NOT NULL DEFAULT b'1',
`thumbUrl` varchar(255) DEFAULT NULL,
`upc` varchar(255) DEFAULT NULL,
`arm` int(11) DEFAULT NULL,
`bridge` int(11) DEFAULT NULL,
`caliber` int(11) DEFAULT NULL,
`gender` varchar(255) DEFAULT NULL,
`lensColor` varchar(255) DEFAULT NULL,
`material` varchar(255) DEFAULT NULL,
`model` varchar(255) NOT NULL,
`sphere` decimal(10,2) DEFAULT NULL,
`type` varchar(255) NOT NULL,
`taxRate_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `UK_k7s4esovkoacsc264bcjrre13` (`sid`),
UNIQUE KEY `UK_ajh6mr6a6qg6mgy8t9nevdym1` (`sku`),
UNIQUE KEY `UK_boqikmg9o89j8q0o5ujkj33b3` (`upc`),
KEY `idx_manufacturer` (`manufacturer`),
KEY `idx_brand` (`brand`),
KEY `idx_line` (`line`),
KEY `idx_colorcode` (`colorCode`),
KEY `idx_preset` (`preset`),
KEY `idx_manufacturer_model_color_caliber` (`manufacturer`,`model`,`colorCode`,`caliber`),
KEY `FK1nau29fd70s1nq905dgs6ft85` (`taxRate_id`),
CONSTRAINT `FK1nau29fd70s1nq905dgs6ft85` FOREIGN KEY (`taxRate_id`) REFERENCES `taxrate` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=392179 DEFAULT CHARSET=utf8;


The query is created programatically from my application. The "strange" syntax (NULL IS NULL OR condition) is very convenient to me in order to make more compact my code and removing the need to create a different query based on the numbers of parameters.



For who understand how Hibernate HQL and JPA works, this is the query:



enter image description here



This query is generated when the user is not setting any filter, so all parameters in my condition are null and this is how the query comes out.



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_ 
WHERE (NULL IS NULL OR NULL LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturer` LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturerCode`=NULL OR frame0_.`sku`=NULL OR frame0_.`upc`=NULL OR frame0_.`line` LIKE CONCAT('%', NULL, '%') OR frame0_.`model` LIKE CONCAT('%', NULL, '%')) AND (NULL IS NULL OR frame0_.`manufacturer`=NULL) AND (NULL IS NULL OR frame0_.`line`=NULL) AND (NULL IS NULL OR frame0_.`caliber`=NULL) AND (NULL IS NULL OR frame0_.`type`=NULL) AND (NULL IS NULL OR frame0_.`material`=NULL) AND (NULL IS NULL OR frame0_.`model`=NULL) AND (NULL IS NULL OR frame0_.`colorCode`=NULL)


The query takes about 0.105s on a table of 137548 rows.
The EXPLAIN of the previous query returns:



id  select_type table   partitions  type    possible_keys   key key_len ref rows     filtered   Extra
1 SIMPLE frame0_ N ALL N N N N 137548 100.00 N


The previous query is identical to this one:



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_


This query takes just 0.05s for the same result in the same table.



Why for Mysql they are different and the first is taking so much time? Is there a way to improve performance of the first query keeping the syntax "NULL IS NULL or condition"?










share|improve this question




















  • 1




    The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
    – Ryan Wilson
    Nov 19 at 20:40










  • I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
    – drenda
    Nov 19 at 21:02










  • No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
    – Ryan Wilson
    Nov 19 at 21:08










  • For "re-work your end of things" do you mean build the query based on which filters the user selects?
    – drenda
    Nov 19 at 21:10










  • I suppose so, but you said your current query already takes care of that?
    – Ryan Wilson
    Nov 19 at 21:12













up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm getting some strange timing values from Mysql running a "simple" query.



This is the DDL of the table:



CREATE TABLE `frame` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`createdBy` varchar(255) DEFAULT NULL,
`createdDate` datetime(6) NOT NULL,
`lastModifiedBy` varchar(255) DEFAULT NULL,
`lastModifiedDate` datetime(6) DEFAULT NULL,
`sid` varchar(36) NOT NULL,
`version` bigint(20) NOT NULL,
`brand` varchar(255) DEFAULT NULL,
`category` varchar(255) DEFAULT NULL,
`colorCode` varchar(255) DEFAULT NULL,
`colorDescription` varchar(255) DEFAULT NULL,
`description` longtext,
`imageUrl` varchar(255) DEFAULT NULL,
`lastPurchase` datetime(6) DEFAULT NULL,
`lastPurchasePrice` decimal(19,2) DEFAULT NULL,
`lastSell` datetime(6) DEFAULT NULL,
`lastSellPrice` decimal(19,2) DEFAULT NULL,
`line` varchar(255) DEFAULT NULL,
`manufacturer` varchar(255) DEFAULT NULL,
`manufacturerCode` varchar(255) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`preset` bit(1) NOT NULL DEFAULT b'0',
`purchasePrice` decimal(19,2) DEFAULT NULL,
`salesPrice` decimal(19,2) DEFAULT NULL,
`sku` varchar(255) NOT NULL,
`stock` bit(1) NOT NULL DEFAULT b'1',
`thumbUrl` varchar(255) DEFAULT NULL,
`upc` varchar(255) DEFAULT NULL,
`arm` int(11) DEFAULT NULL,
`bridge` int(11) DEFAULT NULL,
`caliber` int(11) DEFAULT NULL,
`gender` varchar(255) DEFAULT NULL,
`lensColor` varchar(255) DEFAULT NULL,
`material` varchar(255) DEFAULT NULL,
`model` varchar(255) NOT NULL,
`sphere` decimal(10,2) DEFAULT NULL,
`type` varchar(255) NOT NULL,
`taxRate_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `UK_k7s4esovkoacsc264bcjrre13` (`sid`),
UNIQUE KEY `UK_ajh6mr6a6qg6mgy8t9nevdym1` (`sku`),
UNIQUE KEY `UK_boqikmg9o89j8q0o5ujkj33b3` (`upc`),
KEY `idx_manufacturer` (`manufacturer`),
KEY `idx_brand` (`brand`),
KEY `idx_line` (`line`),
KEY `idx_colorcode` (`colorCode`),
KEY `idx_preset` (`preset`),
KEY `idx_manufacturer_model_color_caliber` (`manufacturer`,`model`,`colorCode`,`caliber`),
KEY `FK1nau29fd70s1nq905dgs6ft85` (`taxRate_id`),
CONSTRAINT `FK1nau29fd70s1nq905dgs6ft85` FOREIGN KEY (`taxRate_id`) REFERENCES `taxrate` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=392179 DEFAULT CHARSET=utf8;


The query is created programatically from my application. The "strange" syntax (NULL IS NULL OR condition) is very convenient to me in order to make more compact my code and removing the need to create a different query based on the numbers of parameters.



For who understand how Hibernate HQL and JPA works, this is the query:



enter image description here



This query is generated when the user is not setting any filter, so all parameters in my condition are null and this is how the query comes out.



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_ 
WHERE (NULL IS NULL OR NULL LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturer` LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturerCode`=NULL OR frame0_.`sku`=NULL OR frame0_.`upc`=NULL OR frame0_.`line` LIKE CONCAT('%', NULL, '%') OR frame0_.`model` LIKE CONCAT('%', NULL, '%')) AND (NULL IS NULL OR frame0_.`manufacturer`=NULL) AND (NULL IS NULL OR frame0_.`line`=NULL) AND (NULL IS NULL OR frame0_.`caliber`=NULL) AND (NULL IS NULL OR frame0_.`type`=NULL) AND (NULL IS NULL OR frame0_.`material`=NULL) AND (NULL IS NULL OR frame0_.`model`=NULL) AND (NULL IS NULL OR frame0_.`colorCode`=NULL)


The query takes about 0.105s on a table of 137548 rows.
The EXPLAIN of the previous query returns:



id  select_type table   partitions  type    possible_keys   key key_len ref rows     filtered   Extra
1 SIMPLE frame0_ N ALL N N N N 137548 100.00 N


The previous query is identical to this one:



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_


This query takes just 0.05s for the same result in the same table.



Why for Mysql they are different and the first is taking so much time? Is there a way to improve performance of the first query keeping the syntax "NULL IS NULL or condition"?










share|improve this question















I'm getting some strange timing values from Mysql running a "simple" query.



This is the DDL of the table:



CREATE TABLE `frame` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`createdBy` varchar(255) DEFAULT NULL,
`createdDate` datetime(6) NOT NULL,
`lastModifiedBy` varchar(255) DEFAULT NULL,
`lastModifiedDate` datetime(6) DEFAULT NULL,
`sid` varchar(36) NOT NULL,
`version` bigint(20) NOT NULL,
`brand` varchar(255) DEFAULT NULL,
`category` varchar(255) DEFAULT NULL,
`colorCode` varchar(255) DEFAULT NULL,
`colorDescription` varchar(255) DEFAULT NULL,
`description` longtext,
`imageUrl` varchar(255) DEFAULT NULL,
`lastPurchase` datetime(6) DEFAULT NULL,
`lastPurchasePrice` decimal(19,2) DEFAULT NULL,
`lastSell` datetime(6) DEFAULT NULL,
`lastSellPrice` decimal(19,2) DEFAULT NULL,
`line` varchar(255) DEFAULT NULL,
`manufacturer` varchar(255) DEFAULT NULL,
`manufacturerCode` varchar(255) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`preset` bit(1) NOT NULL DEFAULT b'0',
`purchasePrice` decimal(19,2) DEFAULT NULL,
`salesPrice` decimal(19,2) DEFAULT NULL,
`sku` varchar(255) NOT NULL,
`stock` bit(1) NOT NULL DEFAULT b'1',
`thumbUrl` varchar(255) DEFAULT NULL,
`upc` varchar(255) DEFAULT NULL,
`arm` int(11) DEFAULT NULL,
`bridge` int(11) DEFAULT NULL,
`caliber` int(11) DEFAULT NULL,
`gender` varchar(255) DEFAULT NULL,
`lensColor` varchar(255) DEFAULT NULL,
`material` varchar(255) DEFAULT NULL,
`model` varchar(255) NOT NULL,
`sphere` decimal(10,2) DEFAULT NULL,
`type` varchar(255) NOT NULL,
`taxRate_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `UK_k7s4esovkoacsc264bcjrre13` (`sid`),
UNIQUE KEY `UK_ajh6mr6a6qg6mgy8t9nevdym1` (`sku`),
UNIQUE KEY `UK_boqikmg9o89j8q0o5ujkj33b3` (`upc`),
KEY `idx_manufacturer` (`manufacturer`),
KEY `idx_brand` (`brand`),
KEY `idx_line` (`line`),
KEY `idx_colorcode` (`colorCode`),
KEY `idx_preset` (`preset`),
KEY `idx_manufacturer_model_color_caliber` (`manufacturer`,`model`,`colorCode`,`caliber`),
KEY `FK1nau29fd70s1nq905dgs6ft85` (`taxRate_id`),
CONSTRAINT `FK1nau29fd70s1nq905dgs6ft85` FOREIGN KEY (`taxRate_id`) REFERENCES `taxrate` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=392179 DEFAULT CHARSET=utf8;


The query is created programatically from my application. The "strange" syntax (NULL IS NULL OR condition) is very convenient to me in order to make more compact my code and removing the need to create a different query based on the numbers of parameters.



For who understand how Hibernate HQL and JPA works, this is the query:



enter image description here



This query is generated when the user is not setting any filter, so all parameters in my condition are null and this is how the query comes out.



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_ 
WHERE (NULL IS NULL OR NULL LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturer` LIKE CONCAT('%', NULL, '%') OR frame0_.`manufacturerCode`=NULL OR frame0_.`sku`=NULL OR frame0_.`upc`=NULL OR frame0_.`line` LIKE CONCAT('%', NULL, '%') OR frame0_.`model` LIKE CONCAT('%', NULL, '%')) AND (NULL IS NULL OR frame0_.`manufacturer`=NULL) AND (NULL IS NULL OR frame0_.`line`=NULL) AND (NULL IS NULL OR frame0_.`caliber`=NULL) AND (NULL IS NULL OR frame0_.`type`=NULL) AND (NULL IS NULL OR frame0_.`material`=NULL) AND (NULL IS NULL OR frame0_.`model`=NULL) AND (NULL IS NULL OR frame0_.`colorCode`=NULL)


The query takes about 0.105s on a table of 137548 rows.
The EXPLAIN of the previous query returns:



id  select_type table   partitions  type    possible_keys   key key_len ref rows     filtered   Extra
1 SIMPLE frame0_ N ALL N N N N 137548 100.00 N


The previous query is identical to this one:



SELECT SQL_NO_CACHE COUNT(frame0_.`id`) AS col_0_0_ FROM `Frame` frame0_


This query takes just 0.05s for the same result in the same table.



Why for Mysql they are different and the first is taking so much time? Is there a way to improve performance of the first query keeping the syntax "NULL IS NULL or condition"?







mysql hibernate jpa






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 19 at 20:58

























asked Nov 19 at 20:36









drenda

1,47222353




1,47222353








  • 1




    The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
    – Ryan Wilson
    Nov 19 at 20:40










  • I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
    – drenda
    Nov 19 at 21:02










  • No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
    – Ryan Wilson
    Nov 19 at 21:08










  • For "re-work your end of things" do you mean build the query based on which filters the user selects?
    – drenda
    Nov 19 at 21:10










  • I suppose so, but you said your current query already takes care of that?
    – Ryan Wilson
    Nov 19 at 21:12














  • 1




    The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
    – Ryan Wilson
    Nov 19 at 20:40










  • I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
    – drenda
    Nov 19 at 21:02










  • No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
    – Ryan Wilson
    Nov 19 at 21:08










  • For "re-work your end of things" do you mean build the query based on which filters the user selects?
    – drenda
    Nov 19 at 21:10










  • I suppose so, but you said your current query already takes care of that?
    – Ryan Wilson
    Nov 19 at 21:12








1




1




The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
– Ryan Wilson
Nov 19 at 20:40




The difference in execution time is .05 seconds, not even 1/10th of a second. I don't see why you think performance has degraded so poorly. In the first query it has to do comparisons and LIKEs which would almost always perform slower than a straight up select from table t
– Ryan Wilson
Nov 19 at 20:40












I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
– drenda
Nov 19 at 21:02




I see your point but I'm expecting a much larger amount of data on production enviroment. My intent using that syntax was to prevent Mysql to make a real filter when the first condition (NULL IS NULL) is true. So, avoiding to make a filter when the user doesn't set values. Sorry the picture was not uploaded before. Thanks
– drenda
Nov 19 at 21:02












No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
– Ryan Wilson
Nov 19 at 21:08




No worries. If the user desides to not provide filters, then they are going to just have to deal with the slower load. Unless you want to re-work your end of things.
– Ryan Wilson
Nov 19 at 21:08












For "re-work your end of things" do you mean build the query based on which filters the user selects?
– drenda
Nov 19 at 21:10




For "re-work your end of things" do you mean build the query based on which filters the user selects?
– drenda
Nov 19 at 21:10












I suppose so, but you said your current query already takes care of that?
– Ryan Wilson
Nov 19 at 21:12




I suppose so, but you said your current query already takes care of that?
– Ryan Wilson
Nov 19 at 21:12












1 Answer
1






active

oldest

votes

















up vote
0
down vote













I think Ryan has right, so the many or statement made the query so bad.



You should programatically build queries for better performance. So if the user not select by a possible filter, than you shouldn't include to the query!



(HQL)



if(!StringUtils.isEmpty(manufacturer)) {
query.and(m.manufacturer.eq(manufacturer))
}





share|improve this answer





















    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%2f53382262%2fslow-query-with-null-is-null-or-condition-syntax-using-mysql-5-7%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    I think Ryan has right, so the many or statement made the query so bad.



    You should programatically build queries for better performance. So if the user not select by a possible filter, than you shouldn't include to the query!



    (HQL)



    if(!StringUtils.isEmpty(manufacturer)) {
    query.and(m.manufacturer.eq(manufacturer))
    }





    share|improve this answer

























      up vote
      0
      down vote













      I think Ryan has right, so the many or statement made the query so bad.



      You should programatically build queries for better performance. So if the user not select by a possible filter, than you shouldn't include to the query!



      (HQL)



      if(!StringUtils.isEmpty(manufacturer)) {
      query.and(m.manufacturer.eq(manufacturer))
      }





      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        I think Ryan has right, so the many or statement made the query so bad.



        You should programatically build queries for better performance. So if the user not select by a possible filter, than you shouldn't include to the query!



        (HQL)



        if(!StringUtils.isEmpty(manufacturer)) {
        query.and(m.manufacturer.eq(manufacturer))
        }





        share|improve this answer












        I think Ryan has right, so the many or statement made the query so bad.



        You should programatically build queries for better performance. So if the user not select by a possible filter, than you shouldn't include to the query!



        (HQL)



        if(!StringUtils.isEmpty(manufacturer)) {
        query.and(m.manufacturer.eq(manufacturer))
        }






        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 19 at 21:56









        László Tóth

        765




        765






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53382262%2fslow-query-with-null-is-null-or-condition-syntax-using-mysql-5-7%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Wiesbaden

            Marschland

            Dieringhausen