Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I would try limiting the number of products to 30 <strong>first</strong> and then joining with only 30 products:</p> <pre><code> SELECT p.*, GROUP_CONCAT(pt.name) as tags FROM (SELECT p30.* FROM products p30 ORDER BY p30.created LIMIT 30) p LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id) LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id) GROUP BY p.id ORDER BY p.created </code></pre> <p>I know you said <strong>no subqueries</strong> but you did not explain why, and I don't see any other way to solve your issue. </p> <p>Note that you can eliminate the subselect by putting that in a view: </p> <pre><code>CREATE VIEW v_last30products AS SELECT p30.* FROM products p30 ORDER BY p30.created LIMIT 30; </code></pre> <p>Then the query is simplified to:</p> <pre><code> SELECT p.*, GROUP_CONCAT(pt.name) as tags FROM v_last30products p LEFT JOIN product_tags_for_products pt4p ON (pt4p.product_id = p.id) LEFT JOIN product_tags pt ON (pt.id = pt4p.product_tag_id) GROUP BY p.id ORDER BY p.created </code></pre> <p>Other issue, your <code>n-to-n</code> table <code>product_tags_for_products</code></p> <p>Does not make sense, I'd restructure it like so:</p> <pre><code>CREATE TABLE `product_tags_for_products` ( `product_id` mediumint(8) unsigned NOT NULL, `product_tag_id` int(10) unsigned NOT NULL, PRIMARY KEY (`product_id`,`product_tag_id`), CONSTRAINT `product_tags_for_products_ibfk_1` FOREIGN KEY (`product_id`) REFERENCES `products` (`id`), CONSTRAINT `product_tags_for_products_ibfk_2` FOREIGN KEY (`product_tag_id`) REFERENCES `product_tags` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci </code></pre> <p>This should make the query faster by:<br> - shortening the key used (On InnoDB the PK is always included in secondary keys);<br> - Allowing you to use the PK which should be faster than using a secondary key; </p> <p><strong>More speed issues</strong><br> If you replace the <code>select *</code> with only the fields that you need <code>select p.title, p.rating, ... FROM</code> that will also speed up things a little. </p>
    singulars
    1. This table or related slice is empty.
    1. POOptimising MySQL query on JOINed tables with GROUP BY and ORDER BY without using nested queries
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJohan
    1. USJohan
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POOptimising MySQL query on JOINed tables with GROUP BY and ORDER BY without using nested queries
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThat'd be a subquery. It also means that if I want to filter by tag in the future, by adding a WHERE clause or changing to an INNER JOIN, then it's quite likely that I'll get less than 30 results.
      singulars
      1. PO
      1. USBen
    2. COThe `EXPLAIN` posted by OP suggests that MySQL restricts the products table to 30 rows in the very beginning.
      singulars
      1. PO
      1. USSalman A
    3. CO@SalmanA Indeed, which confuses me, as why should it then take so long?
      singulars
      1. PO
      1. USBen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload