Timeline for COUNT and GROUP BY performance
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 21, 2014 at 20:04 | history | edited | bartover | CC BY-SA 3.0 |
adding missing half of a sentence
|
| Jun 21, 2014 at 20:02 | comment | added | bartover |
@ypercube absolutely, hence FOR EACH ROW trigger syntax :-). That said, we're facing a logging table here so rows are written out one-by-one anyway. Given this and the "Query blocking note" paragraph I don't see any immediate problems (correct me if I'm wrong, though). In a perfect world the application would be putting any low-priority logging information onto an EMS queue that would get written out to a database or a warehouse at a time of least traffic precisely to avoid unnecessary database contention.
|
|
| Jun 21, 2014 at 16:44 | vote | accept | yoshi | ||
| Jun 21, 2014 at 15:15 | comment | added | ypercubeᵀᴹ | I guess you know that MySQL triggers are row-based so they might be more of a problem in a write-intensive load (I mean more than keeping an index updated.) | |
| Jun 21, 2014 at 14:17 | history | answered | bartover | CC BY-SA 3.0 |