Let's suppose the database table is set up in such a way that this "date" field is being indexed for rapid retrieval of specific values, but this index doesn't help for queries that end up having to do some test on every value (e.g. "greater than this and less than that") -- maybe such a query ends up just doing a full-table scan because the index can't be used that way. (Maybe the "explain" facility will make that clear.)

If that's the case, it's possible that the rephrasing suggested by McDarren might save the day, if it allows the query conditions to be tested against the values in the index, rather than the values in the table itself.

But in case that doesn't pan out, it becomes a question of how to specify the query for those 100's of specific values in a more sensible way (i.e. not just making a list of 100's of values conjoined with "OR"). One possible solution would be to create a temporary table (just one column is needed), load it with the target values, and set the query to something like:

SELECT sum(numlog) FROM table1 WHERE date IN (SELECT date from temptab
+le)
[download]

Don't forget to drop (or at least clear) the temp table when you're done. And bear in mind that you would need to be very careful if this is being done as part of a web app. (You don't want different clients using the same temp table, and you don't want too many clients creating lots of big temp tables at the same time...)

You are using a current version of MySQL, aren't you? The ability to do a sub-query select statement like that has been around since the transition to version 5.