• Resolved treminaor

    (@treminaor)


    EXPLAIN SELECT SQL_CALC_FOUND_ROWS wp5_posts.ID, CAST( orderby_event_date_meta.meta_value AS DATETIME ) AS event_date FROM wp5_posts INNER JOIN wp5_postmeta ON ( wp5_posts.ID = wp5_postmeta.post_id ) LEFT JOIN wp5_postmeta AS orderby_event_date_meta ON ( orderby_event_date_meta.post_id = wp5_posts.ID AND orderby_event_date_meta.meta_key = '_EventStartDate' ) WHERE 1=1 AND ( ( wp5_postmeta.meta_key = '_EventStartDate' AND CAST(wp5_postmeta.meta_value AS DATETIME) > '2019-01-01 00:00:00' ) ) AND wp5_posts.post_type = 'tribe_events' AND ((wp5_posts.post_status = 'publish')) GROUP BY wp5_posts.ID ORDER BY event_date ASC, wp5_posts.post_date ASC LIMIT 0, 10\G
    * 1. row *
    id: 1
    select_type: SIMPLE
    table: wp5_posts
    partitions: NULL
    type: ref
    possible_keys: PRIMARY,type_status_date
    key: type_status_date
    key_len: 164
    ref: const,const
    rows: 3596
    filtered: 100.00
    Extra: Using index; Using temporary; Using filesort
    * 2. row *
    id: 1
    select_type: SIMPLE
    table: wp5_postmeta
    partitions: NULL
    type: ref
    possible_keys: post_id,meta_key
    key: post_id
    key_len: 8
    ref: semiwiki_word5.wp5_posts.ID
    rows: 7
    filtered: 2.26
    Extra: Using where
    * 3. row *
    id: 1
    select_type: SIMPLE
    table: orderby_event_date_meta
    partitions: NULL
    type: ref
    possible_keys: post_id,meta_key
    key: post_id
    key_len: 8
    ref: semiwiki_word5.wp5_posts.ID
    rows: 7
    filtered: 100.00
    Extra: Using where
    3 rows in set, 2 warnings (0.00 sec)

    I am doing a performance review of our server and this events calendar query is filling up the slow query log.

    SQL_CALC_FOUND_ROWS is deprecated and should not be used. Additionally I couldn’t even run this query in mysql without changing my config to disable ONLY_FULL_GROUP_BY in sql_mode.


    I got the following advice regarding the rest of the query:

    • If possible, consider optimizing the GROUP BY and ORDER BY operations to reduce the need for temporary tables and filesorts.
    • Evaluate the necessity of SQL_CALC_FOUND_ROWS in the query. If the total row count is not crucial for the use case, removing this clause can improve query performance.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support Jes

    (@jescandoit)

    Hey @treminaor,

    I appreciate you’re time and effort in diagnosing this query issue. I will make a note of this and pass it on to our developers.

    Have a great day ahead!

    Plugin Support Darian

    (@d0153)

    Hi @treminaor

    I’m glad you brought this to our attention, I can see how this issue impacts the performance of your website.

    We’ve created an internal ticket [TEC-4568] to address this issue and I’ve included your specific use case in it to communicate it to our team.

    We prioritize bugs by taking into consideration the number of users impacted as well as how the bug impacts one’s ability to run an event/sell tickets. I don’t have a specific timeline as to when this issue will be resolved, but trust that our team is aware. Our team communicates updates and bug fixes in our newsletter and via our changelog.

    I’m happy to help if any other questions are coming up around this topic, otherwise I’ll go ahead and close this ticket.

    Thanks again for reporting this issue and for using The Events Calendar! Have a great day.

    Internal Bug Ticket Reference: TEC-4568

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Badly performing SQL query’ is closed to new replies.