# Alarm Journal Query Efficiency: suboptimal JOIN order causing performance issues?

**URL:** <https://forum.inductiveautomation.com/t/alarm-journal-query-efficiency-suboptimal-join-order-causing-performance-issues/114036>\
**Category:** Ignition\
**Tags:** perspective, ignition83\
**Created:** [February 18, 2026, 5:01pm UTC](https://forum.inductiveautomation.com/t/alarm-journal-query-efficiency-suboptimal-join-order-causing-performance-issues/114036 "2026-02-18T17:01:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![ricardo.palma](https://avatars.discourse-cdn.com/v4/letter/r/eb8c5e/32.png) [@ricardo.palma](https://forum.inductiveautomation.com/u/ricardo.palma)\
**Post date:** [February 18, 2026, 5:01pm UTC](https://forum.inductiveautomation.com/t/alarm-journal-query-efficiency-suboptimal-join-order-causing-performance-issues/114036/1 "2026-02-18T17:01:42Z")

</div>

Hi everyone,

I've been troubleshooting some significant performance bottlenecks with the Alarm Journal component (Perspective) using a MySQL backend. We have a large dataset, and querying historical alarms was taking an excessive amount of time, sometimes leading to timeouts.

After deep-diving into the MySQL slow query logs and analyzing the execution plans, I noticed the generated query structure seems suboptimal.

Here is the query generated by the component:

SELECT d.`id`, d.`propname`, d.`dtype`, d.`intvalue`, d.`floatvalue`, d.`strvalue`  
FROM alarm\_event\_data d  
LEFT JOIN alarm\_events e ON d.`id` = e.`id`  
WHERE e.`eventtime` \>= '2026-01-28 15:36:51.309'  
AND e.`eventtime` \<= '2026-02-18 15:36:51.309'  
AND ((e.`priority` = 1 OR e.`priority` = 2 OR e.`priority` = 3 OR e.`priority` = 4)  
AND e.`eventflags` & 1 = 0);

The issue:

The query performs a "FROM alarm\_event\_data d LEFT JOIN alarm\_events e". However, all the filtering logic (timestamp range, priority, flags) is applied to the "alarm\_events" table (the right side of the join).

Since we are filtering by "eventtime", wouldn't it be much more efficient for the query to be structured as "FROM alarm\_events JOIN alarm\_event\_data"? By starting with "alarm\_event\_data" (which holds the raw values and has significantly more rows), the database optimizer seems to struggle to use the indexes on "alarm\_events` effectively, occasionally forcing full table scans or inefficient nested loops.

Is there a way to force the Alarm Journal to optimize this join order?

Has anyone else experienced this specific behavior with MySQL and found a workaround (besides throwing massive amounts of RAM/IOPS at the DB)?

Thank you very much!

---

<div class="post-metadata">

**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\
**Post date:** [February 18, 2026, 5:08pm UTC](https://forum.inductiveautomation.com/t/alarm-journal-query-efficiency-suboptimal-join-order-causing-performance-issues/114036/2 "2026-02-18T17:08:20Z")

</div>

No idea about forcing the Alarm Journal to optimize the join/use a custom query, but typically throwing more ram at a query is not as good a solution as a well placed index. Show the EXPLAIN of the query and it should become clear where you might be able to improve performance.