eRKa

Если памяти не хватает, то без разницы сколько потоков Вы используете. Многопоточность нужна либо для асинхронности, либо для параллельности. Добавление потоков памяти не сэкономит, даже наоборот, увеличит ее расход и даже иногда скорости не добавляет.

Если у Вас есть некий список, с которым работает много потоков, то рассмотрите возможность использования потокобезопасных коллекций. List не потокобезопасен.

Если у Вас большой объем данных, который не влазит в память, то только подгружать данные частями, если хотите добавить параллельную обработку этих данных в разных потоках, то ,возможно, Вам подойдет Parallel.ForEach.

И да, нет необходимости добавлять 100 потоков, как уже сказали, такое кол-во в кол-во ядер не влезет и производительности это не добавит, а даже наоборот, т.к. одно ядро будет делить время на часть выделенных потоков и будет переключать контекст между ними. Не факт, конечно, что даже два потока будут разделены по ядрам, за это ОС отвечает, но 100 потоков, это кажется перебором. Можно, конечно поэкспериментировать с кол-вом и посмотреть на производительность при этом.

У Вас не правильный подход. Во первых забудьте про Thread и используйте TPL. Во вторых для распараллеливания запросов в цикле есть замечательный метод Parallel.ForEach. В третьих для ожидания выполнения всех параллельных задач есть Task.WaitAll.
В общем Вы можете создать список Task-ов и запихнуть их в Task.WaitAll, но лучше пройдитесь параллельным форичем по Вашему периоду и внутри запускайте Ваши методы. Код за форичем будет ожидать завершения всех потоков в цикле.

Можно попробовать эти проверочные поля вынести в код, сделать этот объект доступным для всех потоков. Поток, прежде, чем сделать запрос, сначала в список заносит id строки, ответ получил - из списка этот id удалил. Другие потоки, прежде чем сделать запрос, проверяют список, если id есть в списке, то в ожидание.
Тут может быть та же проблема, но с меньшей вероятностью, поэтому проверка должна быть двойная: сначала проверил, что id нет такого, добавил, потом проверил, что их не два в списке и только тогда запрос. Если два, то удалил и с таймаутом пытается опять добавить.
Я не знаю Ваших объемов бд, но как второй вариант рассмотреть нормальные очереди запросов. Перед запросом проверить есть ли очередь с именем айдишника, если нет, то создать и последующие запросы просто будут добавляться в свою очередь.

Используя в чистом виде thread Вам придется руками контролить множество нюансов, когда в TPL это все сделается за Вас. Рекомендуется использовать TPL.

В первую очередь надо понимать разницу между аснихронностью и паралельностью.
Во вторых, чтобы и то и другое иметь возможность использовать, надо знать жизненный цикл приложения, в частности asp mvc.
В третьих, под знанием многопоточности понимается знание примитивов синхронизации и когда в каких задачах их использовать.
В четвертых, под умением распаралеливать задачи в .net, подразумевается знание библиотеки TPL и умение ею пользоваться.