Я пока не вижу преимущества использования переменной @fl вместо REPLACE запроса.

if @fl is null then
insert into groupsbrands
(gid, sname)
values (new.gid, @fl);

Уникальное поле (UNIQUE) тоже будет работать в REPLACE запросе.

По-шагово.

Триггер запускается для первой записи.
@fl = null
sname = 'DVD'
@fl = 'DVD'
т.к. @fl <> null, второй запрос не выполняется.

Триггер запускается для второй записи.
@fl = null
sname = не понятно что (ноль байт)
@fl = ноль байт (по-Вашему) или текущее значение, т.е. null (по-моему)
т.к. @fl <> null, второй запрос не выполняется (по-Вашему)
или @fl = null, второй запрос выполняется (по-моему).

Тут я не понимаю. Если правы Вы (ноль байт - это не null), тогда мой триггер не должен выполнить второй запрос на вставку. Но он выполняется. Значит, прав я (значение переменной @fl не изменяется).

>>ноль байт - это не null! Это важно!

Я думал, что если условие первой выборки не удовлетворено, то значение переменной @fl не изменяется. Выходит, по-Вашему, в этой переменной теперь будет ноль байт? Но как тогда второй запрос запускается? Ведь там задано условие is null?

-- Объявили пользовательскую переменную @fl.
set @fl = null;

-- Здесь в переменную @fl попадает значение из поля sname выбираемое по gid. Поле gid - это первичный ключ?
-- Обратите внимание, что если значение запроса не найдено, то в переменной @fl будет 0 байт в бинарном виде (ноль байт - это не null! Это важно!).
select
sname into @fl
from groupsbrands
where groupsbrands.gid = new.gid;

-- Если в переменной @fl находится null значение (null - это не ноль байт), то выполняем вставку строки.
if @fl is null then
insert into groupsbrands
(gid, sname)
values (new.gid, new.sname);
end if;

Я не вижу смысла в такой конструкции, поэтому предложил REPLACE, ведь вы все-равно используете поле gid для выборки значения поля sname в первом запросе SELECT.

REPLACE INTO `csv_vvv` (`csv_vvv`.`id`, `csv_vvv`.`text`) VALUES (NEW.`id`, NEW.`text`);

Думаю это оптимальный вариант. Но проверка уникальности проходит по первичному ключу, а не по значению.

В вашем случае код триггера будет такой:

DROP TRIGGER IF EXISTS `tovar_bi`;
DELIMITER //
CREATE TRIGGER `tovar_bi` BEFORE INSERT ON `tovar`
  FOR EACH ROW BEGIN
    REPLACE INTO `groupsbrands` (`groupsbrands`.`gid`, `groupsbrands`.`sname`) VALUES (NEW.`gid`, NEW.`sname`);
end
//
DELIMITER ;

Чтобы узнать, есть ли такая запись, делается выборка из таблицы 2 в переменную @fl. Если эта переменная содержит что-нибудь, значит такая запись уже есть. Если же переменная равна null, тогда записи еще нет, и делается вставка.

Скорее странно почему раньше работало. Хотя и сейчас код не идеален.

Но я не могу разобраться в вашем триггере без структуры таблиц и без примера данных.

Вот код (добавил первую строку):

CREATE TRIGGER `tovar_bi` BEFORE INSERT ON `tovar`
FOR EACH ROW begin

set @fl = null; #это добавленная строка

select
sname into @fl
from groupsbrands
where groupsbrands.gid = new.gid;

if @fl is null then
insert into groupsbrands
(gid, sname)
values (new.gid, new.sname);
end if;
end

Почему этот код не работал без этой строки и почему работает теперь?

CREATE TABLE IF NOT EXISTS `csv` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `text` tinytext NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 ;


CREATE TABLE IF NOT EXISTS `csv_vvv` (
  `id` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
  `text` tinytext NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8 ;

DROP TRIGGER IF EXISTS `csv_trigger`;
DELIMITER //
CREATE TRIGGER `csv_trigger` BEFORE INSERT ON `csv`
 FOR EACH ROW BEGIN
    INSERT INTO `csv_vvv` SET `csv_vvv`.`text` = NEW.`text`;
end
//
DELIMITER ;

Пример CSV файла csv.csv:

1;"fdsa"
2;"vvv"