Собственно, есть 2 физических факторов торможения баз данных.
Первый фактор связан с объемом данных в оперативной памяти.
На таблицах в несколько десятков мегабайт он оказывается решающим.
Второй фактор связан с файловой системой компьютера. Таблица - это файл; индекс - это еще один файл. На ноутбуке критическим порогом размера файла является 50-70 Мб. Если размер файла таблицы или индекса больше, начинает лавинообразно расти время дерганий головки винчестера по кластерам. На машинах с быстрыми винчестерами порог начинается с 200-250 Мб.

Посмотри большие форумы: не случайно везде поотключали полнотекстовый поиск: индекс слишком велик, никакими конфигурациями сервера не потянуть. На движках типа phpBB2, в которых не предусмотрен полнотекстовый поиск, а лишь LIKE, поиск приходится отрубать еще раньше: когда сама таблица дорастет до критического размера.

В чём проблема хранить яйца отдельно, колбасу отдельно? В одной таблице товары с id-производителя, в другой производители. Поиск по таблице производителей будет очень быстрым даже если юзать like, т.к. их всего-то сотня максимум.
Изучайте связанные запросы или ваш проект будет падать от каждой сотни посетителей (

Так же очень рекомендую почаще использовать explain

Ну проблема как раз в этом и заключается, что это будет система поиска информации.

Табличка которую я привел в примере тестовая. Естественно в реальном проекте производители, товары, категории в разных таблицах связанные по id.

А вот без поиска по названию и описанию товара не обойтись вообще никак, потому, что это и есть основная идея проекта. Это не один интернет магазин в котором 500-2000 товаров. Это около 1000 магазинов с довольно широким асортиментом. В будущем количество магазинов будет расти.

Так это будет система ПОИСКА информации или система ВЫБОРА информации? Я потому спрашиваю, что как-то весьма смутно представляю, для чего при поиске понадобится выбирать сразу 2 млн. записей. Всё равно ни одному юзеру столько не надо. Он просто не в состоянии будет даже заголовки прочитать, не говоря уж о содержании.
Да и при выборе тоже столько не нужно. Так что надо изначально продумать оптимальный алгоритм поиска, чтобы выбирать как можно меньше данных, только то, что нужно. И ни байтом больше!

Это будет система поиска. Естественно, что 2 млн записей выбираться не будут. Я не совсем правильно поставил вопрос изначально.

Будет что то на подобии поисковой системы по интернет магазинам, которые регистрируются и указывают свою xml с товарами. Из xml товары попадают в базу и участвуют в поиске. Ну вот для этого всего добра надо будет сделать систему поиска.

Вопрос заключается в том, каким образом реализовать нормальный поиск по довольно большому количеству товаров.

В БД будет таблица товаров связанная с таблицей категорий, таблицей брендов, таблицей магазинов, таблицей акций и.т.д. Таким образом скорей всего придется делать довольно сложные запросы к БД что бы вытащить нужную информацию.

Волнует скорость выполнения таких запросов и нагрузка на сервер, потому что посещаемость планируется не маленькая.

Я пока даже не буду поднимать вопрос "нечеткого поиска". Когда при вводе пользователем "Nokia 5100", "Nokia5100", "5100 Nokia Xpress Music" должны вываливаться одни и те же товары. Так же пока не учитываю алгоритма отсекания стоп слов: "купить дешево ", "купить в Москве" и.т.д. Все это не просто, и пока реализовываться не будет.

Сейчас хочется четко определиться с вопросами:

1) Стоит ли использовать MySQL для этого проекта? Не будет ли падать таблицы БД при больших объемах записей от 1000000 примерно до 10000000?

2) При грамотном проектировании БД и оптимизации запросов, будут ли они выполняться в разумных временных пределах и насколько при этом будут нагружать сервер?

P.S. Я понимаю, что вопрос очень абстрактный. Все зависит от многих факторов. Хочу просто узнать у людей разрабатывающих крупные посещаемые проекты, о приделах MySQL. Просто не раз видел в интернете материалы по поводу того, что критическим размером таблицы для MySQL является 100-150 Мб. Мол при объемах больше запросы работают очень медленно и сервер не выдерживает нагрузки.

1) На ваше усмотрение. 10000000 записей не говорят о том, что все они будут постоянно участвовать в выборках.
2) Будут

Чтобы не делать очень сложные запросы, могу посоветовать денормализовать таблицы введя избыточные данные. Этим вы снизите нагрузку пожертвовав некоторой частью дискового пространства.
Не забывайте о кэшировании. Мускуль хоть и умеет кэшировать, но вот для этого всё-равно необходимо устанавливать с ним соединение, а пул коннектов не безграничен.

Пока не увидел ни одного запроса (даже схематичного), чтобы сказать, будет он нагружать ваш сервер бд до изнеможения или нет. В идеальном случае сферического сервера в вакууме - не будет нагружать.