Here is the complete message in English, formatted as plain text ready to be copied and pasted into your support ticket.
---
**Subject:** URGENT - Critical issue with query lacking WHERE clause crashing campaigns (6.2M records)
Dear Mumara Support,
I am facing a critical issue that is making it impossible to use the platform. Campaigns get stuck in "preparing" or "scheduling" status due to an inefficient query.
After extensive technical diagnostics, **we have identified the root cause** and have definitive proof of the problem.
###
**THE PROBLEM**
The query executed by Mumara:
```sql
SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers AS s
```
**does NOT have a WHERE clause**, unnecessarily scanning **6,296,196 records** on every execution.
This causes:
- Processes stuck in "Creating sort index" in MySQL
- Extreme slowness (minutes)
- Campaigns crashing/freezing
- The need to manually kill processes
###
**THE DEFINITIVE PROOF**
We created indexes (`idx_full_cover`, `list_id`, `idx_list_id_updated`) and tested the query both with and without a WHERE clause.
**Without WHERE (as Mumara executes it):**
```sql
EXPLAIN SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers s WHERE 1=1;
```
Result:
- rows: **6,264,471**
- Extra: Using index (but still scans everything)
**With WHERE (as it should be):**
```sql
EXPLAIN SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers s WHERE list_id = 556;
```
Result:
- rows: **1**
- key: list_id
- type: ref
This proves that:
- The indexes are correct
- The database is optimized
- The server has sufficient resources
-
**The Mumara code does not filter by list_id**
###
**REQUIRED SOLUTION**
We need the development team to **alter the source code** so the query includes `WHERE list_id = X` (or correctly uses `FORCE INDEX`).
As the code is obfuscated (ionCube), we cannot make this correction manually.
###
**TECHNICAL INFORMATION**
- Mumara Version: 6.6.2
- PHP: 8.3.28
- MySQL: MariaDB 11.4.9
- Total subscribers: 6,296,196
- Indexes created: `list_id`, `idx_list_id_updated`, `idx_full_cover`
###
**CURRENT IMPACT**
To work around the problem, we had to create an **automatic monitoring script** that kills slow processes every 30 seconds:
```bash
# Script log (just from today)
2026-02-27 16:49:09 - Process 1382920 killed
2026-02-27 16:50:09 - Process 1383015 killed
...
```
This is a PALLIATIVE measure and does not solve the root cause.
### **REQUEST**
Please correct the Mumara source code so the query on the `subscribers` table uses `WHERE list_id = X` or `FORCE INDEX (idx_full_cover)`.
We await an urgent solution, as the system is currently practically unusable.
Sincerely,
[Your Name]
---
### **ATTACHMENTS (copy and paste along with the message)**
```
=== TECHNICAL EVIDENCE ===
1. Table size:
total_subscribers: 6,296,196
2. Existing indexes:
- PRIMARY (id)
- list_id
- idx_list_id_updated (list_id, updated_at)
- idx_email_list (email, list_id)
- idx_full_cover (id, email, user_id, list_id, updated_at)
3. EXPLAIN without WHERE (current):
rows: 6,264,471 | key: idx_full_cover | Extra: Using index
4. EXPLAIN with WHERE (correct):
rows: 1 | key: list_id | type: ref
5. Script log (processes killed in 1 hour):
2026-02-27 16:49:09 - Process 1382920 killed
2026-02-27 16:50:09 - Process 1383015 killed
2026-02-27 16:51:09 - Process 1383123 killed
2026-02-27 16:52:09 - Process 1383220 killed
```
---
**Subject:** URGENT - Critical issue with query lacking WHERE clause crashing campaigns (6.2M records)
Dear Mumara Support,
I am facing a critical issue that is making it impossible to use the platform. Campaigns get stuck in "preparing" or "scheduling" status due to an inefficient query.
After extensive technical diagnostics, **we have identified the root cause** and have definitive proof of the problem.
###
**THE PROBLEM**The query executed by Mumara:
```sql
SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers AS s
```
**does NOT have a WHERE clause**, unnecessarily scanning **6,296,196 records** on every execution.
This causes:
- Processes stuck in "Creating sort index" in MySQL
- Extreme slowness (minutes)
- Campaigns crashing/freezing
- The need to manually kill processes
###
**THE DEFINITIVE PROOF**We created indexes (`idx_full_cover`, `list_id`, `idx_list_id_updated`) and tested the query both with and without a WHERE clause.
**Without WHERE (as Mumara executes it):**
```sql
EXPLAIN SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers s WHERE 1=1;
```
Result:
- rows: **6,264,471**
- Extra: Using index (but still scans everything)
**With WHERE (as it should be):**
```sql
EXPLAIN SELECT s.id, s.email, s.user_id, s.list_id, s.updated_at FROM subscribers s WHERE list_id = 556;
```
Result:
- rows: **1**
- key: list_id
- type: ref
This proves that:
-
The indexes are correct-
The database is optimized-
The server has sufficient resources-
**The Mumara code does not filter by list_id**###
**REQUIRED SOLUTION**We need the development team to **alter the source code** so the query includes `WHERE list_id = X` (or correctly uses `FORCE INDEX`).
As the code is obfuscated (ionCube), we cannot make this correction manually.
###
**TECHNICAL INFORMATION**- Mumara Version: 6.6.2
- PHP: 8.3.28
- MySQL: MariaDB 11.4.9
- Total subscribers: 6,296,196
- Indexes created: `list_id`, `idx_list_id_updated`, `idx_full_cover`
###
**CURRENT IMPACT**To work around the problem, we had to create an **automatic monitoring script** that kills slow processes every 30 seconds:
```bash
# Script log (just from today)
2026-02-27 16:49:09 - Process 1382920 killed
2026-02-27 16:50:09 - Process 1383015 killed
...
```
This is a PALLIATIVE measure and does not solve the root cause.
### **REQUEST**
Please correct the Mumara source code so the query on the `subscribers` table uses `WHERE list_id = X` or `FORCE INDEX (idx_full_cover)`.
We await an urgent solution, as the system is currently practically unusable.
Sincerely,
[Your Name]
---
### **ATTACHMENTS (copy and paste along with the message)**
```
=== TECHNICAL EVIDENCE ===
1. Table size:
total_subscribers: 6,296,196
2. Existing indexes:
- PRIMARY (id)
- list_id
- idx_list_id_updated (list_id, updated_at)
- idx_email_list (email, list_id)
- idx_full_cover (id, email, user_id, list_id, updated_at)
3. EXPLAIN without WHERE (current):
rows: 6,264,471 | key: idx_full_cover | Extra: Using index
4. EXPLAIN with WHERE (correct):
rows: 1 | key: list_id | type: ref
5. Script log (processes killed in 1 hour):
2026-02-27 16:49:09 - Process 1382920 killed
2026-02-27 16:50:09 - Process 1383015 killed
2026-02-27 16:51:09 - Process 1383123 killed
2026-02-27 16:52:09 - Process 1383220 killed
```